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The invention concerns a terminal com- 
prising a terminal module (1) and a personal se- 
curity device (31). The terminal (1) is adapted 
for receiving requests from an application (Fap) 
implanted on an electronic unit in the form of 
high level requests independent of the module (1) 
and of said personal security device (31). One at 
least of the terminal module (1) and the personal 
security device (31) comprises a reprogrammable 
storage memory and means for executing a filter 
software (F) translating the high level requests 
into at least one of (i) at least one data exchange 
sequence between the terminal module (1) and 
the user or (ii) at least an elementary command 
or sequence of commands executable by the per- 
sonal security device, and means for protecting 
said filter software (F, .62) to prevent any modifi- 
cation of said software by a non-authorised per- 
son. The filter software comprises means for identifying and/ or authenticating the origin of requests transmitted by said application (Fap) 
implanted in said unit. 
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(57) Abr6ge 


Ce terminal comprend un module terminal (1) et un dispositif personnel de securitd (31). Le terminal (1) est adapt6 pour recevoir des 
requetes d'une application (Fap) implantee sur une unit6 61ectronique sous la forme de requetes de haut niveau indfpendants du module (1) 
et dudit dispositif personnel de stairitd (31). L'un au moms du module terminal (1) et du dispositif personnel de security (31) comprend 
une memoire reprogrammable de stockage et des moyens d*ex6cution d'un logiciel filtre (F) traduisant les requetes de haut niveau en au 
moins Tune de (i) au moins une sequence d'echange de donnees entre le module terminal (1) et l'utilisateur ou (ii) au moins une commande 
elemental ou une sequence de commandes elementaires executables par le dispositif personnel de security, ainsi que des moyens de 


protection dudit logiciel filtre (F, 62), pour empecher toute modification dudit logiciel par une personne non autoris6e. Le logiciel filtre 
comprend des moyens d'identification et/ou d'authentification de l'origine des requites emises par ladite application (Fap) implantee dans 
ladite unite\ 
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♦ 

Terminal et svsteme pour la mise en oeuvre df> transac tions plprtrnnjgues s&-uri<A^ 

La prSsente invention concerne un terminal et un systeme pour la mise en oeuvre de 
transactions electroniques securis£es. 

Les reseaux publics de transmission de donnees numeriques, tels que le reseau 
Internet, connaissent un developpement considerable. Cependant, I'un des freins qui 
5 limitent actuellement la mise en oeuvre de transactions electroniques sScurisees sur ce type 
de reseau reside dans Pinsuffisance des mecanismes de security associes k de telles 
transactions, insuffisance qui se traduit par un manque de confiance des utilisateurs et 
op6rateurs de reseaux. 

Au sens de la pr^sente demande : 
10 - une transaction electronique designe un ^change d'informations, via un reseau public, 

de transmission de donnees numeriques ou de telecommunications, soit entre deux ou 
plusieurs utilisateurs, soit entre un utilisateur et un fournisseur de services, 

-une fonction est un traitement effectue dans i'objectif de rendre un service k uri utilisateur, 

- une application designe un ensemble coherent de services et de fonctions; 

1 5 - ('expression logiciel duplication designe le ou les logiciels necessaires pour mettre en 

oeuvre les fonctions relatives k une application donn£e, 

- une transaction securisee est une transaction pour laquelle certaines. mesures de 
s<§curite sont prises, k savoir ['authentication des entites participant k la transaction, 
I'integrite, la confidential ite, I'authenticitiS, et 4ventuellement la non repudiation des 

20 ^changes et operations effectu^es dans le cadre de la transaction. 

De nombreuses applications necessitent que les transactions electroniques mises en 
oeuvre soient securis^es. II s'agit par exemple du contrdle d'acc^s k des ressources 
informatiques ou similaires, de la banque £ domicile (consultation, mouvements de comptes 
bancaires, etc... par I'intermediaire du r6seau telephonique ou d'lnternet), du commerce 
25 electronique (achat de biens ou services par I'intermediaire d'un reseau public), du courrier 
electronique, du porte-monnaie eiectronique, etc.. 

Ces applications, ainsi que d'autres, necessitant des transactions securisees sont bien 
connues des sp^cialistes de la technique et ne sont pas d^crites ici en details. 

Suivant leur nature, la securisation de ces applications necessite la mise en oeuvre d'un 
30 ou plusieurs services de security tels que : 

- I'authentification, qui permet de garantir I'identite d'une entite (une personne ou un sysfeme) ; 

- le contrdle d'accSs, qui confere une protection centre I'utilisation ou la manipulation 
non autoris£e de ressources ; 

- la confidentialite, qui interdit la divulgation de donnees k des entites non autorisees ; 
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- I'integrite de donnees, qui assure que des donnees n'ont pas £te modifiees, supprirrtees 
ou substitutes sans autorisation ; 

- la non repudiation, qui assure qu'un participant k un echange de donnees ne pourra 
pas ulterieurement nier ['existence de cet echange. 

5 La combinaison de deux techniques existantes permet d'envisager la mise en ceuvre 

de ces services de security offrant ainsi un niveau de securite suffisant pour effectuer des 
transactions eiectroniques. 
Ils'agitde: 

- la cryptographie k de publique et cl6 privee, car elle permet de garantir la non 
10 repudiation et facilite la gestion des des ; 

- la carte k circuit integre (ou "smart card") car elle est peu couteuse, facile k utiliser et 
sure grace k des microprocesseurs specifiques dotes de protections materielles et logicielles 
permettant d'interdire I'acc6s en lecture et en Venture k leurs memoires. 

Les cartes k circuit integre offrent les services suivants : 
1 5 * I 'authentification du porteur ou utilisateur de la carte : cette operation pemnet d'authentifier le 

porteur k I'aide d'un code confidentiel et k la carte d'accepter par la suite la mise en ceuvre 
d'operations telles que ('execution d'algorithmes, la lecture de des secretes, la lecture et/ou I'ecriture 
de donnees dans la carte, qui peuvent en outre etne soumises k d'autres conditions de securite ; 

* la protection des donnees et fonctions stockees sur la carte k circuit integre. L'acc^s k la 
20 carte peut etre soumis k une authentication ptealable de I'entite electronique demandant k y 

aoteder. Cette authentication exteme se fait gengralement en mode challenge/reponse. Dans ce 
cas, I'entite dispose d'un parametre secret, cypres appele egalement secret, qui lui permet de 
calculer, en fonction d'un challenge emis par la carte, une teponse qui prouvera k la carte qu'elle 
est en possession du secret ; 
25 * execution d'algorithmes cryptographiques utilisant un parametre secret memorise dans la 

carte (chiffrement, authentification de message, signature) ; 

* authentification interne. Ce service permet k une application d'authentifier la carte. Ce 
service est I'inverse d'une authentification exteme. La carte g6n£re une reponse en fonction d'un 
challenge regj et d'un secret stocke dans la carte. 

30 Les services offerts par la carte k circuit integre sont mis en ceuvre sur reception de 

cornmandes dites el£mentaires, I'execution de la commande elementaire provoquant I'envoi 
de reponses elementaires. Ces cornmandes elementaires concernent, par exemple, des 
calculs cryptographiques, la lecture ou I'ecriture de donnees secretes ou non, des 
interventions de I'utilisateur (saisie de son code confidentiel personnel PIN, validation d'une 
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transaction apr6s signature), les retours d' information vers I'utilisateur (affichage des 
messages k signer, par exemple). 

Certaines cartes offrent la possibility de verifier NntegritS, I'origine, voire (a 
confidentiality des commandes envoyees k la carte. Ces services reposent sur des techniques 
5 d'authentification et de chiffrement des commandes. 

L'utilisation qui est faite actueilement des cartes k circuit integrS (ou cartes k micro- 
circuit) offre un degr6 tr£s 6leve de securite car les transactions sont essentiellement mises en 
oeuvre sur des reseaux priv^s et des terminaux (distributeurs automatiques de billets, 
terminaux points de vente par exemple) qui sont sous le contrdle d'une entite assurant la 
1 0 securite de I'ensemble du systeme. 

Dans de telles applications, les utilisateurs ou d'eventuels fraudeurs n'ont pas acc6s au logiciel 
d' application, ni aux m£canismes de security materiels et logiciels dont sont dotes les terminaux. 

Par contre, la mise en ceuvre de transactions securisees avec des cartes k circuit integre sur 
un reseau public suppose que les utilisateurs aient k leur disposition un module terminal lecteur 
1 5 de carte, 6tant donnS que ces cartes k micro-circuit ne sont pas dotees d'une source d'6nergie 
electrique propre et que leur mise en oeuvre requiert un lecteur susceptible de les alimenter et 
d'6tablir une communication avec I'utilisateur et/ou des moyens 6lectroniques exterieurs. 

A I'heure actuelle, pour rSaliser une transaction sur un r6seau public, I'utilisateur 
dispose d'un terminal, qui peut etre un produit d£di£, un ordinateur personnel, ou un 
20 ordinateur personnel couple k une carte k circuit integr6 par un lecteur de carte. 

Dans tous les cas, le systeme de transactions k la disposition de I'utilisateur est en 
general constitu£ de : 

• un foumisseur de services applicatifs pouvant etre, par exemple, un navigateur Internet, 
un logiciel de messagerie, un logiciel de banque k domicile ("Home banking"), 
25 • un foumisseur de services de securite de haut niveau permettant ['execution des 
m^canismes cryptographiques de bas niveau requis par I'appiication. 

Le foumisseur de services applicatifs emet des requetes de services de security de haut 
niveau pour assurer la security des transactions mises en oeuvre. 

Dans le cas ou I'appiication est implantee sur I'ordinateur personnel de I'utilisateur, les 
30 services cryptographiques auxquels il est fait reference sont, par exemple, ceux d^finis par la 
Soctete RSA Laboratories dans son standard "PKCS 1 1 : Cryptographic Token Interface 
Standard", ou encore les services cryptographiques offerts par le systeme d'exploitation 
Windows NT de Microsoft, en particulier ceux proposes par ('Interface des programmes 
duplication (API) "Crypto API". 
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Lorsque I'utilisateur ne dispose pas de lecteur de carte k circuit integre, les services 
cryptographiques sont realises de mantere logicielle uniquement.. 

Lorsque I'utilisateur veut amEliorer la securite, il utilise un lecteur de carte k circuit 
integre de type transparent connecte a son ordinateur. Un lecteur de carte de type 
5 transparent est en fait un boitier d'interface entre I'ordinateur et la carte k circuit integre qui 
permet de transmettre des commandes elementaires de I'ordinateur, provenant du 
foumisseur de services cryptographiques, vers la carte, et les rEponses Elementaires de la 
carte vers I'ordinateur. Un utilisateur peut, k I'aide de ce terminal, (constitue de son module 
terminal - ordinateur + lecteur - couple k sa carte) effectuer des transactions electroniques 
1 0 (commerce Electronique par exemple). 

Bien entendu, I'acc&s des utilisateurs k un tel terminal engendre des risques potentiels 
du point de vue de la sEcurite. 

Les risques encourus seront d'autant plus grands que les applications seront 
d6centralisees. Et vice versa, les applications pourront Stre d'autant plus decentralisees, que 
15 les risques cfit6 terminaux seront maitrisEs. Par exemple, on peut envisager des applications 
de type porte-monnaie, dans lesquelles les transactions (dEbit de la carte acheteur/credit de 
la carte commergant) se feront de carte k carte, sans necessiter une consolidation des 
transactions au niveau d'un serveur central. 

II rEsulte de ce qui precede, qu'un terminal peut potentiellement contenir un 
20 ensemble d'informations, voire des logiciels, sur la confidentiality et I'integrite desquels 
repose la sEcuritE de I'application. Comme exemple, on peut citer des cl£s secretes utilisees 
pour I'authentification du module terminal vis-^-vis de la carte, ou pour le chiffrement de 
donnEes entre un serveur et le module terminal lecteur de carte. Or, un fraudeur peut 
profiter du fait d'avoir k sa disposition un terminal pour analyser son fonctionnement et 
25 acceder aux informations et logiciels confidentiels. 

II faut Egalement noter que les applications auxquelles il est fait reference ici, telles 
que le commerce ou le courrier Electronique, sont la plupart du temps mises en oeuvre k 
travers le reseau Internet. II est bien connu des experts qu'un ordinateur personnel ou PC 
connecte au rEseau Internet est trEs vulnerable aux logiciels de type virus, qui peuvent etre 
30 installes et executes sur le PC de I'utilisateur sans m£me qu'il le sache et sans qu'il ait laissE 
un acc&s physique k son ordinateur k qui que ce soit. Le c6t6 totalement invisible de ce type 
de menace reprEsente le r£el danger qui limite k I'heure actuelle le dEpIoiement des 
applications transactionnelles utilisant Internet. Les mfimes commentaires peuvent 
s'appliquer aux applications de commerce Electroniques envisagees k partir des reseaux 
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cables de television en utilisant des d^codeurs ou "set-top box" raccord§s au poste de 
television et comportant un ou deux iecteurs de cartes ^ puce. 
Les risques au niveau du systeme sont alors les suivants : 

• Attaque sur Tintegrite du foumisseur de services cryptograph iques et du fournisseur de 
5 services applicatifs visant k modifier le comportement du module terminal : a titre 

d'exemple, le module terminal est modifte de manure k capturer les informations liees k la 
carte, stacker les informations obtenues pour ensuite les communiquer a un faux serveur. 
Cette attaque peut Stre r^alisee k I'insu de I'utilisateur legitime (substitution du module 
terminal de I'utilisateur ou pr£t d'un module terminal modifiy). Cette attaque peut ensuite se 
10 generaliser sous la forme de la diffusion de modules terminaux contrefaits ; 

• Attaque sur la confidentiality du fournisseur de services cryptographiques, visant k se 
procurer les cl£s cryptographiques qu'il manipule, lesquelles ctes sont par exemple stockees 
sur le disque dur d'un ordinateur. 

• Attaque vis^-vis d'autres cartes, bas^e sur une capacity Ipouvoir s'authentifier vis^-vis de ces 
1 5 cartes, gr^ce aux secrets decouverts par une attaque sur la confidentiality du foumisseur de sen/ices. 

• Attaque sur I'integrity et la confidential ite des communications entre les differentes 
entitys (foumisseurs de services applicatifs, foumisseurs de services cryptographiques, 
lecteur de carte k circuit int£gr£, carte k circuit intygry, serveur) permettant de rompre la 
chaine de confiance ytablie entre ces elements . Par exemple: 

20 1 - dechiffrement des communications entre serveur et terminaux ; 

2 - insertion d'un logiciel tiers entre le foumisseur de services applicatifs et le foumisseur de 
services cryptographiques visant k rompre la chaine de confiance entre ces deux logiciels ou bien 
substitution du logiciel applicatif par un logiciel tiers visant k faire executer au foumisseur de 
services de security des requites de security dans un but different de celui de ('application 

25 connuede I'utilisateur. 

• Attaque sur les serveurs (dans le cas d'une applicatidn en mode connecte) : connexion 
d'un terminal contrefait k un serveur, Emulation d'un couple module terminal-carte k circuit 
intygry pour obtenir des avantages. 

Ainsi, une attaque sur la chaine de confiance entre le fournisseur de services 
30 cryptographiques et le fournisseur de services applicatifs, dans le cadre d'une application 
requyrant la signature d'une transaction yiectronique k I'aide d'une carte a circuit integre, est 
illustrye ci-aprys. Le dyroulement de la transaction est le suivant : 

- Etape 1 : vyrification du code confidentiel personnel (PIN) de I'utilisateur, que celui- 
ci introduit par un clavier associy k son module terminal, le code introduit etant transmis k la 
35 carte pour vyrification par cette derniyre* 
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- Etape 2 ; authentification du module terminal. Ce dernier envoie une commande 
"demande challenge". (Un challenge est un nombre aleatoire ou pseudo-aleatoire). La carte 
k circuit integrt gtntre le challenge et le transmet au module terminal. Le module terminal, 
envoie k la carte une commande "authentification externe" accompagnee d'une rtponse 

5 constitute du challenge chiffrt par une cle dttenue par le module terminal. La carte k circuit 
inttgre verifie alors la reponse re?ue. 

- Etape 3 : si les ttapes 1 et 2 se sont deroulees de manure satisfaisante, la carte k 
circuit inttgre est prtte k recevoir et executer la commande signature, c'est-^-dire une 
commande de chiffrement, au moyen d'une cle privee stockee dans la carte, du resultat 

10 d'une operation de hachage rtalisee sur la transaction saisie par I'utilisateur. Aprts ce 
chiffrement, la carte tmet, k destination du module terminal, la signature constitute du 
rtsultat de ('operation de hachage ("hash") ainsi chiffrt* 

Si I 'integrity du logiciel duplication (foumisseur de services applicatifs et son 
fourntsseur de services cryptograph iques) n'est pas assuree, un fraudeur n'a pas besoin de 

15 connaitre les cits et codes secrets pour pirater le systeme de transaction : il lui suffit 
d'implanter dans le module terminal, par exemple dans I'ordinateur personnel auquel est 
raccorde un lecteur de carte k circuit inttgrt, un logiciel de type virus qui, k Petape 3, 
detourne les donnees authentiques k signer et envoie k la carte des donntes falsifiees. Etant 
donne que les Stapes 1 et 2 se sont deroulees de manure satisfaisante, la carte signera alors 

20 les donnees falsifies sur la base du PIN que I'utilisateur a lui-meme introduit et celui-ci 
croira que la carte va signer ses propres donnees. 

L'exemple prtcedant montre la necessity de proteger non seulement les informations 
confidentielles mises en oeuvre dans le cadre d'une transaction, mais aussi I'inttgrite de la 
transaction, c'est-^-dire I'inttgrite du comportement de chaque entite intervenant dans la 

25 transaction, ainsi que I'inttgritt du comportement d'ensemble du logiciel en veillant £ la non 
rupture de la chame de confiance ttablie entre les difftrentes entitts. 

Les risques d'attaque mentionnts cwdessus sont k I'heure actuelle en partie couverts 
par des terminaux - lecteurs de carte k circuit integre integrant des modules de securite 
(SAM, analogue k une carte k circuit inttgre) qui sont utilises notamment dans le cadre des 

30 applications porte-monnaie. Le lecteur est alors personnalist par un SAM, et attribue k un 
commergant, les cartes lues ttant celles des clients. Ce SAM contient des informations 
secretes et est susceptible d'extcuter des algorithmes utilisant ces informations secretes. 
Mais, il ne contient pas de moyens permettant notamment de piloter les communications 
avec I'utilisateur, avec la carte k circuit inttgrt et/ou avec des moyens tlectroniques 

35 exttrieurs, et done la stcurisation de transaction n'est pas assurte. 
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II est egalement connu par le document WO 95/04328 un module terminal 
comprenant des moyens d'interface avec Putilisateur et des moyens d'interface avec des 
moyens electroniques exterieurs (ci-apr£s appetes moyens d'interface externe), comportant 
une interface avec une carte k micro-circuit. Le microprocesseur du module terminal 
5 comprend des moyens de stockage de donnees (ROM, EEPROM, RAM). Les donnees 
stock6es en memoire permanente (ROM) comprennent entre autres un systeme 
d'exploitation, des gestionnaires de composants externes pilotant les interfaces et 
peripheriques, et un interpr&eur capable d'interpr&er des modules programmes ecrits dans 
un langage spdcifique. Les modules programmes sont stockSs dans la memoire semi- 

10 permanente EEPROM et peuvent Stre charges en memoire temporaire RAM pour §tre 
executes par le microprocesseur lors de ['activation d'une interface appropriee par 
Putilisateur. Les modules programmes, correspondant aux applications du module terminal, 
sont t6lecharg6s dans la memoire EEPROM du microprocesseur ou dans une carte a micro- 
circuit k partir d'un serveur externe. 

1 5 Le module terminal du document WO95/04328 peut fonctionner : 

- en mode module terminal autonome, le microprocesseur du module terminal executant un 
module programme stocks dans une memoire interne, sans faine appel k une carte k circuit integre ; 

- en mode terminal autonome, dans lequel un module programme stocke dans une carte 
est execute ; 

20 - en mode terminal £tendu ou connecte, dans lequel le microprocesseur du module terminal ou 
celui de la carte execute un module programme et une communication est etablie via le 
telephone, un modem ou une liaison directe avec un foumisseur de services ou un serveur ; 

- en mode lecteur de carte a memoire transparent, dans lequel des instructions revues par 
une liaison s6rie sont transmises directement k la carte et vice et versa. 

25 Le terminal decrit au document WO 95/04328 ne traite pas des probl£mes de securite 

vises par ['invention dans la mesure ou il ne decrit pas comment securiser une transaction en 
garantissant I'integrite du comportement d'ensemble du logiciel executant la transaction. II ne 
d6crit notamment pas de moyens pemnettant l'ex£cution de requfites de haut niveau Emises par 
('application, ni comment garantir I'origine, I'int£grit6 et la confidentiality de ces moyens. 

30 La pr^sente invention vise k fournir un terminal pour la mise en ceuvre de transactions 

Electroniques securis^es, du type comprenant un dispositif personnel de securite tel qu'une 
carte k circuit int6gr6 ou autre dispositif remplissant les memes fonctions, et un module 
terminal dote de moyens d'interface avec le dispositif personnel de securite, tels qu'un 
lecteur de carte k circuit int6gr6, et offrant de par son architecture logicielle et/ou materielle 

35 et les m^canismes de security qu'il comporte, un niveau de securite ameliore, compatible 
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avec le fait que ie terminal peut Stre plac6 sous le contrdle des utiiisateurs, (par opposition k 
des terminaux contrfiles par des opErateurs). 

Un deuxteme objectif de I'invention est d'assurer ce m6me niveau de securite tout en 
permettant ('integration, en cours d'utilisation, de fonctions ou applications nouvelles, ou 
5 I 'evolution des fonctions ou applications existantes sans avoir recours k une multitude de 
modules terminaux differents ou au changement des modules terminaux lors des Evolutions. 

A cet effet, ['invention a pour objet un terminal pour la mise en ceuvre, par un 
utilisateur, de transactions electroniques securisSes en liaison avec au moins une application 
implantee sur une unite electronique, ledit terminal comprenant : 
10 - un module terminal comportant au moins : 

• des premiers moyens d'interface avec ladite application pour en recevoir des 
requites relatives auxdites transactions, 

• des deuxtemes moyens d'interface avec ledit utilisateur, 

• des troistemes moyens d'interface avec un dispositif personnel de securite, 

15 • des premiers moyens de traitement de donnees comprenant au moins des premiers 

moyens logiciels de pilotage desdits moyens d'interface, et 
- un dispositif personnel de securite comportant au moins des deuxiemes moyens de 
traitement de donnees securisEes comprenant au moins des deuxiemes moyens logiciels 
d'exScution de commandes eiementaires et des moyens d'ex&rution de calculs 
20 . cryptograph iques, caracterisE en ce que : 

* ledit terminal est adapts pour recevoir lesdites requetes de ladite application 
implantee sur ladite unite electronique sous la forme de requites de haut niveau 
independantes dudit dispositif personnel de securite, 

* Pun au moins dudit module terminal et dudit dispositif personnel de securite comprend : 
25 • au moins une memoire reprogrammable de stockage d'au moins un logiciel filtre, 

traduisant lesdites requites de haut niveau en en au moins I'une de : 

(i) au moins une commande 6l6mentaire ou une sequence de commandes 

e§lt§mentaires executables par lesdits deuxiemes logiciels desdits deuxiemes 

moyens de traitement de donnEes, ou 
30 (ii) au moins une sequence d'<§change de donnees entre ledit module terminal et 

ledit utilisateur via lesdits seconds moyens d'interface, ledit echange de donnees 

etant execute par lesdits premiers moyens logiciels desdits premiers moyens de 

traitement de donnees, 
• . des moyens de protection dudit logiciel filtre pour empgcher toute lecture 
35 et/ou modification dudit logiciel par une personne non autorisee, et 
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* Tun au moins desdits premiers et deuxi£mes moyens de traitement de donnees 
comprend un dispositif de traitement de donnSes pour Pex£cution dudit logiciel filtre. 
L'invention definie ci-dessus permet d'atteindre les objectifs de security requis par la 
mise en oeuvre de transactions electroniques grace au fait qu'elle d<§crit un filtre ou pare-feu 
5 C firewall ") entre le monde exterieur, c'est-^-dire les applications elles-memes, et les 
moyens de sScurite et p<§riph6riques qu'il g£re, au moyen d'une interface logique permettant 
la definition du format des requites de haut niveau 6mises par les applications et d'un 
logiciel de traduction assurant le traitement de ces requ&es. 

De preference, le terminal suivant ('invention comprend une ou plusieurs des 
1 0 caracteristiques suivantes, 6ventuellement combines : 

- ledit dispositif d'ex^cution du logiciel filtre comprend des premiers moyens 
d' identification et/ou d'authentification de ladite application implant£e dans ladite unite ou 
de I'origine desdites requites 6mises par ladite application ; 

- ledit dispositif de traitement de donnees pour Pex£cution dudit logiciel filtre comprend 
1 5 des moyens de verification de ('integrity des donnees re? ue de ladite application ; 

- ledit dispositif de traitement de donnees pour Pex£cution dudit logiciel filtre comprend 
des moyens centralises de contrdle des conditions d'utilisation des services du dispositif 
personnel de s6curit6, en fonction de ladite application et/ou dudit utilisateur ; 

- ledit dispositif de traitement de donnees pour ('execution dudit logiciel filtre comprend : 
20 • des moyens pour commander le chargement securise dudit logiciel filtre dans 

ladite m^moire programmable, via Pun desdits premiers ou troistemes moyens 
d'interface, k partir d'une entity exterieure audit module, et 
• des premiers moyens de contrdle d'acc&s pour n'autoriser ledit chargement.dudit 
logiciel filtre qu'en reponse k au moins une condition pred£finie ; 
25 - le terminal comprend des deuxi&mes moyens d'authentification desdits premiers 
moyens de traitement de donnees par lesdits deuxi£mes moyens de traitement de donnees ; 

- le terminal comprend des troistemes moyens d'authentification desdits deuxiemes 
moyens de traitement de donnees par lesdits premiers moyens de traitement de donnees ; 

- le terminal comprend un premier canal de communication entre lesdits premiers et 
30 deuxiemes moyens de traitement de donnees et des premiers moyens de securisation dudit 

premier canal de communication ; 

- le terminal comprend des quatrteme moyens d'authentification dudit module terminal 
par ledit utilisateur, ind6pendamment de ladite carte ; 

- lesdits quatrtemes moyens d'authentification comprennent des moyens de calcul, par 
35 lesdits premiers moyens de traitement de donnees, et de presentation audit utilisateur, via 
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lesdits deuxieme moyens d'interface, d'un mot de passe connu dudit utilisateur et calculi sur 
la base d'au moins un premier parametre secret stocke dans lesdits premiers moyens de 
traitement de donnees ; 

- le terminal comprend des cinquiemes moyens d'authentification conjointe dudit module 
5 terminal et de ladite carte par ledit utilisateur ; 

- lesdits cinquiemes moyens d'authentification comprennent des moyens de caicul, par 
ledit dispositif d'execution dudit logiciel, et de presentation audit utilisateur, via lesdits 
deuxiemes moyens d'interface, d'un mot de passe connu dudit utilisateur et calcule sur la 
base d f au moins un deuxieme et un troisteme parametres secrets stockes respectivement 

10 dans lesdits premiers et deuxiemes moyens de traitement de donnees. 

Selon une premiere forme de realisation de ('invention, le module terminal est 
constitue par un ordinateur personnel et ladite memoire programmable est constitute par le 
disque dudit ordinateur, ledit logiciel filtre est execute sur I'ordinateur personnel ou bien 
dans un deuxieme mode d'execution, ladite memoire programmable est implantee sur un 
15 serveur securise relie & I'ordinateur personnel, la partie du logiciel filtre devant etre protege 
etant executee sur ledit serveur securise. 

Selon une deuxieme forme de realisation de ('invention, le module terminal est un 
dispositif, tel qu'un lecteur dedie de carte k circuit integre, auquel cas ledit dispositif 
personnel de securite est une carte k circuit integre, ou un ordinateur personnel. Ce mode de 
20 realisation se difference du precedent par le fait que ladite memoire programmable est 
integree dans un microprocesseur securise, ledit logiciel filtre etant execute dans ledit 
microprocesseur securise. Le module terminal dedie peut eventuellement etre portable. 

Selon les modes d'execution de cette deuxieme forme de realisation de I'invention, la 
memoire programmable pour le chargement et le stockage du logiciel filtre peut etre 
25 disposee dans le dispositif personnel de securite ou dans le module terminal. 
Dans ce dernier cas : 

- le module terminal peut comporter un seul microprocesseur pour ('execution du 
logiciel filtre et le pilotage des interfaces, ou bien deux microprocesseurs remplissant 
respectivement Tune et Tautre de ces deux fonctions. 
30 - de preference ledit logiciel filtre comprend au moins un parametre secret et lesdits 

deuxiemes moyens de traitement de donnees comprennent des seconds moyens de contrdle 
d'acces conditionnels pour n'autoriser I'execution desdits calculs cryptographiques, en 
reponse k des commandes eiementaires generees par ledit logiciel filtre^ que si au moins une 
seconde condition predefinie, fonction dudit parametre secret est remplie 
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Selon d'autres caracteristiques de ('invention, lorsque le module terminal comporte 
deux microprocesseurs pour ['execution du logiciel filtre et le pilotage des interfaces : 

- le terminal comprend un deuxteme canal de communication entre lesdits premiers 
moyens logiciels de pilotage des moyens d'interface et ledit deuxteme microprocesseur et 

5 des deuxtemes moyens de securisation dudit deuxieme canal de communication ; 

- lesdits deuxiemes moyens de securisation comprennent des moyens de chiffrement 
et dechiffrement, par lesdits premiers moyens logiciels de pilotage des moyens d'interface et 
ledit deuxieme microprocesseur, des donnees transmises sur ledit deuxieme canal de 
communication, sur la base d'au moins un cinqui&me parametre secret memorise dans 

1 0 lesdits premiers et deuxiemes moyens de traitement de donnees ; 

- lesdits deuxiemes moyens de securisation comprennent des premiers moyens 
physiques de protection dudit deuxieme canal de communication contre les intrusions. 

Differents modes de realisation de I'invention seront maintenant d6crits en se referant 
aux dessins annexes, en particulier des modes de realisation dans lesquels le logiciel filtre est 
15 charge et execute dans le terminal de manure k garantir k la fois son origine, sa 
confidential ite et son integrity ce logiciel pouvant aussi authentifier I'origine des requites 
qui lui sont envoyees, si la confiance dans les interfaces avec I'utilisateur, c'est-S-dire Pecran 
et le clavier, ne peut etre garantie. 

- la Figure 1 est un schema illustrant I 'architecture fonctionnelle d'un systeme pour la 
20 mise en oeuvre de transactions securis£es au moyen d f un terminal selon ('invention ; 

- la Figure 2A presente une premiere forme de realisation de I'invention ou le terminal 
est un ordinateur personnel couple k une carte k circuit integre par un lecteur, ^application 
pouvant etre elle meme impiantee sur I'ordinateur personnel ou sur un serveur distant. 

- la Figure 2B decrit ('architecture fonctionnelle d'une variante d'execution de la 
25 premiere forme de realisation de I'invention, dans laquelle I'ordinateur personnel servant de 

terminal est en liaison avec un serveur de securite sur lequel est implante le logiciel filtre ; 

- la Figure 3 presente un systeme de transaction mis en oeuvre grace & un terminal 
selon une deuxieme forme de realisation de I'invention, qui peut etre un produit dedie relie 
en tant que peripherique k un ordinateur personnel ou directement k un serveur ou bien 

30 construit autour d'un ordinateur personnel ; 

- la Figure 4A est un schema bloc de ^architecture materielle des circuits 
electroniques d'un premier mode d'execution du terminal de la figure 3 ; 

- la Figure 4B est un schema fonctionnel illustrant une premiere configuration 
d' architecture logicielle du terminal de la figure 4A ; 
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- la Figure 4C est un schema fonctionnel similaire k celui de la figure 4B presentant 
une seconde configuration d'architecture logicielle du terminal de la figure 4A ; 

- la Figure 5 est un schema bloc de I'architecture materielle des circuits electroniques 
d'un deuxteme mode d'execution du terminal autonome de la figure 3 ; 

5 - la Figure 6 est un schema bloc de I'architecture materielle des circuits Electroniques 

d'un troisi&me mode d'execution du terminal autonome de la figure 3 ; 

- la Figure 7 est un schema illustrant I'architecture logicielle conventionnelle d'une 
carte a micro-circuit ; 

- la Figure 8A est un schema illustrant I'architecture logicielle d'un systeme de 
1 0 transaction comprenant le terminal de la figure 4A ; 

- la Figure 8B est un schema illustrant ('architecture logicielle d'un systeme de 
transaction comprenant le terminal de la figure 6 ; 

- la Figure 9 est un diagramme illustrant la mise en oeuvre d'une application de 
commerce electronique au moyen d'un systeme selon I'invention ; et 

15 - la Figure 10 est un organigramme illustrant le processus de telechargement d'un 

programme dans une memoire reprogrammable du module terminal de la figure 4A ou 5, 
ou d'une carte k micro-circuit connects k celui-ci ; 

En se referant k la figure 1, un systeme de mise en oeuvre de transactions s£curis6es 
comprend un module terminal 1 de lecture d'une carte k circuit integr6 31 ou equivalent Le 

20 module terminal 1 comprend un filtre F constitute d'un module logiciel traitant des requetes de 
haut niveau emises par des foumisseurs de services applicatifs FAp extemes au module terminal 1 
au moyen d'une interface logique F-API, et des interfaces utilisateur telles qu'un ecran d'affichage 
4 et un clavier 5 permettant la lecture et ('introduction de donn£es par un utilisateur. II comprend 
egaiement un lecteur ou interface de communication 6 avec une carte k micro-circuit ou tout 

25 dispositif de sEcurite equivalent personnel k I'utilisateur, du type jeton (token), * JavaRing * 
(produit de la societe SUN), * iButton * (produit de la society Dallas Semiconductor Corporation), 
jeton logiciel (soft token), ainsi que des interfaces de communication avec au moins un 
foumisseur de services applicatifs FAp qui peut, par exemple, Stre implants sur un ondinateur 
personnel PC et/ou sur un serveur Sap , i'echange de donnees s'effectuant alors via un reseau R 

30 de transmissions de donnees ou de telecommunications. 

Le module terminal 1 peut §tre un terminal dedte ou Stre integre dans un ordinateur 
personnel de type PC, ou bien dans un ordinateur-terminal NC d6di£ aux applications en reseau 
(Network Computer) ou encore dans un d^codeur de reseau de television cable (Set Top Box). 
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Le module terminal 1 peut eventueilement etre utilise en mode autonome, par exemple 
pour lire des informations, telles que le contenu d'un porte-monnaie electronique, contenues 
dans une memoire de la carte 31 . 

Pour la mise en oeuvre de transactions securisees, le module terminal 1 peut etre 
5 utilise en mode connects avec un serveur Sap ou en mode non connects 1'application FAp 
etant alors executee localement, par exemple sur I'ordinateur personnel PC : Tel est le cas, 
par exemple, lorsqu'un utilisateur doit signer un courrier electronique ou des transactions 
qui seront envoyees k un destinataire. Une telle operation n'implique pas de connexion avec 
un serveur applicatif au moment ou la carte 31 est utilisee. 

1 0 En mode connecte, comme represents a la figure 3 dans le cas d'un module terminal 1 

dedie, celui-ci peut etre connecte au serveur Sap sur iequel est implante ^application FAp 
parTintermediaire de I'orBinateur PC et d'un reseau R tel qu'lnternet, ou par I' intermediate 
du reseau teiephonique R via un modem MO ou une liaison DTMF avec un combine 
teiephonique CT. Certaines transactions, telles que le rechargement d'un porte-monnaie 

15 electron ique dans la carte 31, peuvent necessiter un echange bidirectionnel de donnees 
avec le sen/eur Sap et sont, par consequent, plus ergonomiques en mode connects. 

La mise en oeuvre d'une transaction securisee avec un module terminal 1 et une carte 31 
implique que des requetes logicielles de haut niveau (par exemple des requites de signature, 
d'authentificaition , etc.. qui doivent etre traitees de maniere k satisfaire les objectifs de securite 

20 requis du. programme applicatif) soient transmises du programme applicatif implante par 
exemple dans le serveur Sap (mode connecte) ou dans I'ordinateur personnel PC ou NC k la 
disposition de ('utilisateur (mode non connecte, par exemple signature de courrier 
electronique), au filtre F assurant le pilotage des moyens de securite. Ce filtre F effectue le 
traitement de ces requetes au moyen d'un logiciel de traduction, s'assurant ainsi que 

25 1'application ou tout autre logiciel de type virus ne peuvent avoir un acces direct aux fonctions 
cryptographiques de la carte k circuit integre 31. Le traitement des requetes de haut niveau 
comprend la traduction de ces requetes en une commande elementaire ou une sequence de 
commandes elementaires qui sont executees par le dispositif personnel de securite. Les 
requetes de haut niveau sont formuiees independamment de la configuration materieile et/ou 

30 logicielle du dispositif personnel de securite, c'est-^-dire qu'elles ne sont pas formuiees 
directement en fonction du dispositif personnel de securite. 

Les requetes de haut niveau contiennent des informations qui sont liees specifiquement 
au processus qui sera execute par le logiciel filtre. Selon un exemple simple, une requete de 
haut niveau peut comprendre une commande elementaire unique & transmettre au dispositif 

35 personnel de securite, par exemple un APDU ("Application Protocol Data Unit"), dans le cas 
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d'une carte k microcircuit, attache k un code MAC d'authentification de message qui permettra 
au logiciel filtre F de verifier I'origine et Pintegrite de cette requite avant d'envoyer la 
commande 6l6mentaire au dispositif personnel de securite. Selon un exemple plus complexe, 
tei qu'une requSte de signature d'un document, la requite de haut niveau sera transforms par 
5 le filtre F en une sequence de commandes eiementaires envoytes au dispositif personnel de 
securite et eventuellement k I'interface utilisateur. Ainsi, selon cette definition et du fait qu'elles 
contiennent des informations sp6cifiques devant fitre d&odfes par le filtre F independamment 
du dispositif personnel de securite, les requ&es de haut niveau sont dites Stre indSpendantes 
du dispositif personnel de securite. 
10 Le filtre F rSpond aux objectifs de securite recherches dans la mesure ou le logiciel de 

traduction qu'il comporte verifie I 'identity de ('application emettant les requetes de services 
(ou directement I'origine des requites) et est implante de manure k garantir I'integrite et la 
confidential ite des operations et donnees eiementaires mises en oeuvre pour repondre aux 
requites de services. 

1 5 Un logiciel de traduction est un logiciel configure pour un type de carte k micro-circuit 

et traduit une requgte de haut niveau re?ue d'un logiciel duplication en une commande 
elementaire ou une sequence de commandes eiementaires executables par les cartes k 
micro-circuit et/ou une sequence d'6changes de donnees avec ('utilisateur. 

Les requetes de haut niveau sont une listede commandes utilises par les programmes 

20 applicatifs pour faire appel aux services de securite necessaires pour identifier et authentifier la 
personne tealisant la transaction et garantir I'origine, I'integrite et eventuellement la non- 
repudiation de la transaction. Une requete de haut niveau provenant d'une application (se 
trouvant sur un serveur ou sur I'ordinateur personnel PC ou NQ peut etre caracterisee par un 
ou plusieurs des points suivants : 

25 - elle est ind^pendante des moyens de base (moyens cryptographiques par exemple) 

mis en oeuvre pour satisfaire k sa demande et contient des informations specifiques devant 
6tre traitees par le filtre F. R6ciproquement, plusieurs applications peuvent utiliser le mgme 
fournisseur de services de securite, faisant alors appel k la meme interface logique F-API 
definissant ces requites. 

30 - le traitement de la requite permet de lier la transaction de mantere certaine k 

I'utilisateur effectuant la transaction k I'aide d'au moins un param§tre secret, fixe ou variable, 
stocke dans la carte k circuit integr6 de I'utilisateur. 

- elle comporte eventuellement une information ou des informations permettant au 
logiciel filtre F de verifier son origine et son integrite. L'authentification peut se faire k I'aide 
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d'un code de type " Message Authentication Code ou MAC " ou bien de type * signature 
electronique * associe k la requete. 

- dans le cas ou la transaction n'est pas saisie par I'utilisateur sur le module terminal 
lui-meme, la requete contient eventuellement ^information necessaire pour permettre k 
5 I'utilisateur de verifier, s'il le souhaite et si le module terminal supporte cette option, les 
donnees essentielles de la transaction. 

interface logique F-API permettant I'echange des requetes de security de haut niveau 
entre les applications et le logiciel de traduction du filtre F peut etre standardise de manure k 
etre commune k differents programmes applicatifs. Ainsi, la requite de type * Signature * peut 
10 &re utilise par une messagerie electronique ou par un logiciel d'achat. II est ainsi possible de 
changer ('application tout en conservant le fournisseur de services de securite ou 
reciproquement de remplacer le fournisseur de services de security sans modifier ('application. 

Afin de garantir I'integrite de la chaine de confiance entre I'application et la carte, le 
logiciel filtre F de traduction identifie, voire authentifie I'origine et ('integrity des requetes 
15 qu'il refoit. Differentes methodes peuvent etre envisagees pour identifier . I'application 
emettant les requgtes : 

- un code d'identification peut etre integre dans la requete elle- meme puis v^rifie par le 
logiciel filtre k partir des informations qu'il contient ou qui peuvent etre stockees dans la 
carte £ circuit integre ; 

20 - le meme but peut etre atteint en comparant le r^sultat d'une operation de hachage 
execute par le logiciel filtre sur le logiciel applicatif emettant la requete avec un resultat 
pr£alablement stocke dans la carte par exemple. Cette derniere solution est particulierement 
adaptee au cas ou I'application est implantee sur le PC de I'utilisateur ; 

- ('authentication peut egalement etre realisee en associant k la requete un code de type 
25 * MAC * calcule k partir du contenu de la requete et d'une cie secrete partagee entre 

I'application et le logiciel filtre. Un principe equivalent peut etre utilise avec une signature de la 
requete calcuiee avec les memes informations et une cie privee connue de ('application, la 
signature &ant verifiee avec la cie publique correspondante connue du logiciel filtre. 

La figure 2 A decrit une premiere forme de realisation pour laquelle le module terminal 

30 1 est un ordinateur personnel PC 102, la liaison avec la carte k circuit integre 31 s'effectuant 
au moyen d'un lecteur 6 connecte ou integre k I'ordinateur PC 102. L'ordinateur personnel 
102 comprend des interfaces d'entree/sortie 102a avec le lecteur 6 et le serveur Sap. Suivant 
la nature du lecteur connecte au PC, les elements d'interface avec I'utilisateur peuvent etre le 
clavier et I'ecran du PC lui-meme, ou bien un clavier et/ou un afficheur de type LCD par 

35 exemple implante sur le lecteur. Dans ce mode de realisation, le filtre F est implante et 
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execute sur I'ordinateur PC 102. Le filtre F, et done le logiciel de traduction qu'il contient, 
peut alors etre stocke sur le disque dur HD 102b de I'ordinateur personnel 102. Pour etre 
execute par I'unite de calcul ou microprocesseur 102c du PC, le logiciel filtre est ensuite 
charge dans la'mdmoire vive RAM 102d de I'ordinateur personnel 102. 
5 Le disque dur d'un ordinateur PC font difficile k proteger, le logiciel filtre F, ou tout 

au moins la partie sensible de ce logiciel, peut etre chiffrS. Pour cela il peut etre decompose 
en au moins 2 modules : un module de chargement/dechiffrement Fed et un deuxieme 
module correspondant au logiciel filtre lui-meme chiffre, Fchi. Le premier module permet le 
chargement du deuxieme module en m&noire RAM, son dechiffrement, puis le lancement 

10 de son execution. En se referent k la Figure 2A, le module logiciel dechiffre et charge en 
RAM est nomme Fdec. 

L'utilisation d'un langage de programmation tel que Java, par des mecanismes de 
security intrinseques au langage lui-meme, permet de renforcer la protection du logiciel 

Une autre m&hode de verification de I'integrite du logiciel filtre est de feire signer le 

1 5 deuxieme module par une autorite garante du contenu du logiciel filtre au moyen d'une cle priv6e 
conserve secrete par cette autorite. Le premier module de chargement effectue alors, 
simultan&nent k I'operation de dechiffrement, une operation de hachage sur le deuxteme module et 
verifie la signature de ce module au moyen de la de publique associee k la cle privee de Pautorite. 
L'ensemble des operations decrites dans les paragraphes precedents implique 

20 ('utilisation de cies sur lesquelles reposent la securite de ^application. Ces cies peuvent etre 
cachees dans le module de chargement, stockees dans le lecteur 6, ou bien stockees dans la 
carte k circuit integre 31 elle-mgme. Un autre mode de realisation possible consiste k 
implanter le module de dechiffrement et de verification d'integrite dans le lecteur 6. 

L'objet de I'invention est de s'assurer qu'un pirate ne puisse pas utiliser la carte k 

25 circuit integre d'un utilisateur k son insu, par exemple en modifiant le logiciel filtre pilotant 
la carte ou le logiciel application, ou bien en implantant un logiciel virus qui court- 
circuiterait I'application ou le logiciel filtre mis en place. Le mode de realisation decrit 
prgc&Jemment et ses variantes repondent k ces risques, en permettant la verification: 
- de I'integrite du logiciel filtre et 

30 - de I'origine et de ('integrity des commandes envoy^es k la carte k travers le lecteur 6, en 

les authentifiant k I'aide d'un code de type MAC par exemple. La verification du MAC peut etre 
effectuee par le lecteur 6 ou la carte 31. Une protection equivalente pourrait etre obtenue en 
chiffrant le dialogue entre le logiciel filtre et le lecteur 6. Un logiciel virus cherchant k court- 
circuiter le logiciel filtre enverrait done des commandes non authentifi£es ou incorrectement 

35 chiffr£es au lecteur 6 ou k la carte 31 ; en consequence ces commandes seraient rejetees par le 
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lecteur ou la carte, empSchant le virus d'arriver k ses fins. Afin qu'un fraudeur ne puisse 
determiner les des utilises sur un terminal en analysant le fonctionnement d'un autre terminal, 
les cl& utilisees par divers terminaux devront etre diversifiees. 

Les mecanismes de chiffrement et de signature qui peuvent fitre envisages pour repondre 
5 au besoin de protection du logiciel filtre sont bien connus des hommes de I'art et reposent sur 
les techniques cryptographiques existantes exposes, par exennple, dans Touvrage de Bruce 
Schneier intitule "Applied Cryptography, Protocols, Algorithms, and Source Code in C" publie 
chez John Wiley and Sons, Inc., 1 994, et qui ne seront done pas decrits en detail ici. 

L'implantation du logiciel filtre dans un ordinateur personnel PC ne permet pas de 

10 garantir le m§me degre de securite qu'une implantation dans un terminal dedie pouvant 
offrir des mecanismes de securite materiels supplemental res comme decrit dans les autres 
forrfies de realisation presences ulterieurement, ces mecanismes procurant une protection 
physique au logiciel filtre et aux secrets qu'il contient. 

Une variante d'execution du mode de realisation de la figure 2A est presente k la 

1 5 figure 2B. Cette variante met k profit la souplesse et la facility de connexion d'un ordinateur 
personnel a un r£seau. Cette connexion permet en effet le deport d'une partie du logiciel 
filtre, et en particulier des secrets, dans un serveur securise Ssec. 

Dans le cas de la Figure 2B, le logiciel filtre est decompose en deux modules logiciels, 
un module F-PC implants sur I'ordinateur personnel PC 102 et un module F-SE implante sur 

20 un serveur de security Ssec. La m£moire programmable k laquelle il est reference 
precedemment et stockant le logiciel filtre, est done dans cette variante d'execution 
implantee dans le serveur securise Ssec, e'est-i-dire hors d'atteinte d'utilisateurs non 
autorises. De mSme, le logiciel filtre, ou tout au moins la partie sensible du logiciel filtre F-SE 
requerant une protection, est execute sur le serveur securise Ssec. 

25 Le module logiciel F-PC implante sur I'ordinateur personnel PC 102 est relie par un 

canal securise CS au serveur de securite Ssec. Ce canal securise est en fait un canal de 
communication chiffre permettant un echange de donnees protege entre les deux modules 
logiciels filtre F-PC et F-SE et eventuellement une authentification reciproque des deux 
modules F-PC et F-SE. Ce canal securise peut, par exemple, reposer sur des protocoles de 

30 communication bien connus tels que SSL. 

L'etablissement de ce canal securise CS permet done au premier module logiciel filtre F-PC 
de transmettre au deuxteme module logiciel filtre F-SE, les requites regues de I'application FAp k 
travers ('interface logique F-API, ainsi que les informations liees k I 'identification de I'application 
emettant ces requites. Ce deuxieme module logiciel F-SE va ensuite, aprfes avoir verifi6 les 

35 informations relatives k ('application et, en fonction de I'application et eventuellement des 
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droits de I'utilisateur, traduire ces requites en une suite de commandes destinees a la carte k puce 
3 1 et au pilotage des echanges de donn<§es avec I'utilisateur. Ces commandes crges par le module 
F-SE sont ensuite envoyees au premier module F-PC qui les aiguille vers ['element concern^ : le 
PC lui m§me pour ce qui conceme les commandes de pilotage des echanges avec I'utilisateur ou 
5 bten la carte k circuit integn*. Pour que les commandes de pilotage des echanges avec I'utilisateur 
puissent 6tre executees sur le PC, le PC devra comporter un module logiciel I, dit interpr&eur. Ce 
logiciel interpreter permet I'affichage de messages sur I'ecran 4 et la saisie d'information par 
I'utilisateur sur le clavier 5. Ce module logiciel interpreteur sera plus pnkrisement decrit en regard 
des figures 4B et 4C 

10 Ce second mode d'execution est bas6 sur les mecanismes decrits k propos du premier 

mode d'execution de la figure 2A en ce qui conceme I'identification de ('application 
(hachage ou signature par exemple) et la protection des commandes envoyees k la carte 
(ajout d'un code de type authentication de message MAC, par exemple). II offre par contre 
un degre de security supSrieur dans la mesure ou le module logiciel filtre F-SE assurant la 

15 traduction des requites de haut niveau revues de ^application Fap est execute dans un 
environnement s<§curis(§. Dans le contexte de ('invention, le serveur Ssec est dit securise s'il 
n'est pas accessible physiquement ainsi que logiquement, c'est dire k travers une connexion 
reseau, k des personnes non autorisees. 

Ce second mode d'execution de la figure 2B est bien adapts k des applications mises en 

20 oeuvre dans un environnement ferme ou privatif contrdie par une autorite centrale, car elle 
n£cessite un serveur protege dont ('administration doit etre centralisee. Ce second mode 
d'execution offre de plus la possibility de definir une politique d'acc£s centralisee aux services 
cryptographiques offerts par la carte k circuit integre. Cette politique d'acc£s peut etre basee sur 
les applications requ£rant les services de la carte et sur les utilisateurs eux mgmes. Elle permet, par 

25 exemple, dans la cas d'une entreprise ayant distribue £ ses employes ou k ses clients des cartes k 
circuit integre leur permettant de signer des courriers electroniques ainsi que des transactions 
bancaires, de s'assurer que seuls les utilisateurs autoris& pourront signer : ce mecanisme peut etre 
mis en oeuvre grace au canal securise CS. A chaque requ&e de signature §mise par une des 
applications consider comme valide par I'entreprise (la messagerie eiectronique et le logiciel de 

30 transactions bancaires), le module logiciel F-SE effectuera une demande d'authentification de 
I'utilisateur. Cette demande peut, par exemple, etre effectu^e en envoyant un nombre alSatoire, 
challenge ou defi via le canal securise CS k la carte 31. Apr6s saisie par I'utilisateur de son code 
confidentiel, la carte k circuit integre calculera un motde passe dynamique en chiffrant le defi k 
I'aide d'une cie secrete qu'elle contient. Le mot de passe sera ensuite transmis via le canal CS au 

35 module logiciel F-SE. Le module logiciel F-SE, connaissant I'utilisateur et done la cl£ secrete 
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contenue dans sa carte, comparers le mot de passe re$u au mot de passe attendu. Ce mecanisme 
connu sous le nom d'authentification en mode challenge - reponse permet au module logiciel F- 
SE de valider I'identite de I'utilisateur. Ceci permet done k I'entreprise ayant remis les cartes a 
circuit integre aux utilisateurs de s'assurer que seuls les utilisateurs encore autorises peuvent par 
5 exemple signer des transactions bancaires. 

Le serveur Ssec, grace aux moyens s6curis& et centralises qu'il represente, permet non 
seuiement une implantation s6curis6e du logiciel filtre F-SE mais aussi la possibility de mettre en 
place une politique centralist de contrdle de I'utiiisation des services de security offerts par la 
carte k circuit integre. Le serveur Ssec permet la mise en place d'une politique centralisee du fait 

1 0 qu'un mfime serveur peut etre en liaison avec une plurality des modules logiciets F-PC implantes 
sur les ordinateurs personnels d'une plurality d'utilisateurs. Le serveur Ssec permet ainsi la 
definition et le contrdle centralists des conditions d'utilisation des services de security offerts par 
les cartes remises aux differents utilisateurs, en fonction du profil de ('application requ&ant les 
services etdes droits desdits utilisateurs. La mise en place de cette politique centralisee implique 

1 5 done de stocker dans le serveur les informations necessaires, c'est-4-dire les droits des utilisateurs 
d'utiliser tel service de securite en liaison avec telle application. 

Ce second mode d'execution de la figure 2B, bien adapts aux environnements privts, 
est par contre difficilement applicable k des applications ouvertes pour lesquelles la mise en 
place d'un serveur central securise Ssec n'est pas envisageable. 

20 La Figure 3 illustre un module terminal reprenant des principes d'architecture 

fonctionnelle similaires k ceux de la Figure 2B dans une forme de realisation differente, ne 
ntcessitant pas de serveur centralist. Le module terminal selon la deuxitme forme de 
realisation de la Figure 3 presente un tr£s haut degre de securite, lui permettant ainsi 
d'assurer directement la protection locale du logiciel filtre F. 

25 Dans le cas de la figure 3, le module terminal 1 se presente sous la forme d'un boitier, 

portable ou non, dont une face porte I'tcran d'affichage 4 et le clavier 5 et dans lequel sont 
implantts des circuits electron iques, de preference de manure telle que ceux-ci soient 
inaccessibles depuis I'exterieur. Le boTtier 1 contient le lecteur 6 et presente une ouverture 
de reception de la carte k micro-circuit 31 dans le lecteur 6. Le mode d'execution decrit en 

30 reference aux Figures 3, 4A, 4B et 4C ne doit pas etre consider comme se limitant k un 
terminal dedie. La description qui suit peut tout k fait Gtre appliquee k un terminal construit 
autour d'un ordinateur personnel de type PC ou NC. 

Selon un premier mode d'execution, illustre k la figure 4A, de cette deuxitme forme 
de realisation du module terminal de la figure 3, les circuits electroniques du module 

35 terminal 1 sont organises autour d'un microcontrdleur standard 2 et d'un microprocesseur 3 
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securise\ qui sont connects entre eux par une liaison et implants de manure permanente 
dans le boTtier du module 1 . En variante, le microprocesseur 3 peut fitre enfichable sur le 
module 1 au moyen d'un connecteur 41 represents en traits interrompus a la figure 4A. II est 
decrit ici un mode d'execution g^nerique base" sur un microcontrdleur standard. Dans un 
5 mode d'execution particulier qui sera decrit ulterieurement, le microcontrdleur 2 peut en fait 
Stre un PC 102 du type de celui prgsente" dans la Figure 2B. 

Le microcontrdleur standard 2 comprend une unite de traitement 2a, de la memoire 
temporaire (RAM) 2b, et de la meVnoire permanente (ROM) 2c. II s'agit de preference d'un 
microprocesseur "monochip" dont le programme est masque" dans la memoire permanente 2c 
10 et qui integre dans un meme circuit integre" des moyens de gestion ou pilotage d'interfaces 
standards, 1'unite" de traitement 2a et les me>noires temporaire 2b et permanente 2c. 

Les interfaces ou pe>iph<§riques g<§rees par le microcontrdleur 2 comprennent notamment 
l'<§cran 4 d'affichage de donnees, par exemple a cristaux liquides, le clavier 5 pour ^introduction 
de donnees par un utilisateur, le lecteur 6 de carte a micro-circuit, une interface 7 de liaison 
1 5 exteme, par exemple du type RS 232 ou PCM-CIA, une interface 8 de liaison par infrarouge, et un 
dispositif DTMF 9 pour la transmission de donnees sur une ligne telephonique. 

Les composants du module 1 comprennent Egalement une horloge 10 et une source 
1 1 d'alimentation electrique des different* circuits et composants du module 1. La source 1 1 
d' alimentation electrique peut etre constitute par des piles ou une batterie si le module 1 est 
20 portable et autonome. 

La tfiche du microcontrdleur standard 2 est de gerer Penvironnement, c'est-^dire de piloter 
les interfaces 4-9 et Phorloge 10, ainsi que la source d'alimentation 1 1 pour alimenter s<§leetivement 
le microprocesseur s6curis£ 3 en Snergie Electrique dans le cas d'un module 1 autonome. 

Le microcontrdleur standard 2 nScessite ainsi peu de puissance de calcul, peu de 
25 memoire temporaire (RAM) et pas de m<§moire semi-permanente (EPROM ou EEPROM). Le 
microcontrdleur 2 est protege en 6criture du fait que ses programmes (pilotage d'interfaces 
et, comme decrit dans la suite, interpr&eur, gestion des horloges et de Palimentation 
electrique, etc..,) sont masques en memoire permanente 2c. Comme cela apparaitra dans la 
suite, le microcontrdleur standard 2 peut Sgalement contenir un ou plusieurs param&res 
30 secrets, sur la base desquels il peut 6tre authentifte par le microprocesseur s6curis<§ du 
module terminal et/ou d'une carte k circuit integre. Ces secrets doivent done gtre proteges en 
lecture et en 6criture. lis seront de preference stocks dans la memoire temporaire (RAM) 
d'un microprocesseur "mono chip", qui n'est accessible ni en 6criture, ni en Ecriture depuis 
Pexterieur. Le microcontrdleur standard 2 peut tgalement etre pourvu de fonctions de 
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securite comptementaires, par exemple pour interdire des fraudes telles que I'affichage de 
dbnnees differentes de celles provenant du microprocesseur 3. 

II s'agit par consequent d'un microcontrdleur d'un faible cout et ayant une faible 
consommation electrique, qui est particu I Bremen t adapts k un produit portable. Ce 
5 microcontrdleur peut gtre par exemple du type MSM 63 1 80 de la Society OKI. 

De preference, deux horloges sont prevues en 10 : une horloge a frequence basse 10a, 
par exemple de frequence 32,368 KHz et une horloge k frequence <§lev6e 10b, pouvant aller 
de 1 MHz k 12 MHz par exemple Le microcontrdleur 2 commande la connexion de son 
horloge systeme sur Tune ou l f autre de ces deux horloges. 

10 L'horloge lente 10a cadence un dispositif de temporisation 2d du microcontrdleur 2 

avec une periode de 0,5 s pour realiser une horloge temps n§el dans le module 1 . L'unite de 
traitement 2a peut 6galement fonctionner k I'aide de l'horloge lente 10a pour les fonctions 
ne n£cessitant pas de vitesse de calcul : dans ce cas l'horloge systeme du microcontrdleur 2 
est connects sur l'horloge lente 10a et l'horloge rapide 10b est arr&ee. Ce mode de 

15 fonctionnement permet de limiter la consommation electrique du module 1, ce qui est 
avantageux si celui-ci est portable et aliments par une pile electrique. 

Le microprocesseur 3 s£curis£ en lecture et en £criture comprend une unite centrale 
3a et des memoires temporaire (RAM) 3b et permanente (ROM) 3c, ainsi qu'une memoire 
semi-permanente reprogrammable electriquement (EEPROM ou Flash RAM par exemple) 3d 

20 pour le stockage, entre autres, des programmes duplication du module 1 . 

Ce microprocesseur securise 3 est du type de ceux utilises dans les cartes k micro- 
circuit et il presente un nombre limits d'entr^es et de sortie, ses bus internes etant 
inaccessibles depuis I'exterieur. De par sa fabrication, il integre d'autres mecahismes de 
securite propres k ce type de microprocesseur et bien connus des specialistes de la 

25 technique, tels que matrice de s<§curit<§, brouillage de memoire, contrdle de la frequence 
d'horloge, contrdle de la remise k zero (RESET), etc... 

Grace au fait que le microprocesseur 3 poss£de une memoire semi-permanente 3d, il 
est possible d'y charger depuis l'ext£rieur, par exemple k partir d'un serveur ou d'une carte k 
micro-circuit, un ou des programmes duplication. II est ainsi possible, en fonction des 

30 besoins, de faire Svoluer la ou les applications (contrdle d'acc^s, transaction financiers et/ou 
commerciales, porte-monnaie 6lectronique, etc..) auxquelles est destine le module 1. II est 
egalement possible, si la tail le de la memoire semi-permanente 3d le permet, d'y implanter 
de nouvelles applications au cours de son utilisation. 

Selon la version choisie, le microprocesseur securis6 3 peut assurer le calcul de 

35 fonctions cryptographiques requ^rant des calculs importants mis en ceuvre dans les 
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algorithmes asymetriques de type RSA ou DSA, ou bien mettre en oeuvre des algorithmes 
plus simples, par exemple du type DES. 

Le microprocesseur securise 3 peut fitre, par exemple : 

- un microprocesseur SIEMENS SLE44C160S, non cryptographique, dote de 14 Ko de 
5 memoire ROM et de 1 6 Ko de memoire EEPROM ; 

un microprocesseur SGS THOMSON ST1 6CF54A cryptographique dote de 1 6 Ko de 
memoire ROM, de 4Ko de memoire EEPROM et de 480 octets de memoire RAM ; 

- un microprocesseur PHILiPPS P83C858 cryptographique dote de 20 Ko de memoire 
ROM et de 8 Ko de memoire EEPROM. 

10 Le microprocesseur securise 3 est connecte, d'une part par la liaison 12 au 

microcontraleur standard 2, d'autre part par des liaisons 1 3 et 14 4 I* interface externe 7 et au 
lecteur 6 de carte d micro-circuit par I'intermediaire de commutateurs-adaptateurs d'interface 
15 et 16 respectivement. Les commutateurs-adaptateurs 15 et 16 sont commandes par le 
microcontrfileur standard 2 via des liaisons 17 et 18 respectivement. 

15 Le microcontrdleur standard 2 comprend un programme d" interpretation ou 

interpreter 20 (Fig. 4B et 4C) stocke dans la memoire ROM 2c et permettant k celui-ci 
d*ex6cuter des commandes g^n^rees par le logiciel de traduction des requetes de haut 
niveau faisant partie du ou des programmes duplication, comme cela sera decrit dans la 
suite. Cet interpreter 20 permet ainsi au(x) programme(s) duplication stocke(s) dans le 

20 microprocesseur securise 3 de piloter les interfaces 4-9 via la liaison 12. Cependant, le ou les 
programmes duplication peuvent fitre localises et executes ailleurs que dans le 
microprocesseur 3 securise en lecture et en Venture, par exemple dans une carte a micro- 
circuit 31 inserSe dans Pinterface 6, telle qu'une carte adaptee pour supporter des 
m^canismes de telechargement et d'execution des applications comme decrit dans la norme 

25 NF EN 726-3 intituiee "Cartes k circuit integre et terminaux pour les telecommunications. 
Partie 3 : Specifications de la carte independantes des applications". 

Les programmes d'application peuvent en outre, en fonction des regies de securite. 
auxquelles ils sont soumis, etre distribues entre ces differentes localisations. 

Le schema fonctionnel de la figure 4B illustre une premiere configuration 

30 d'architecture logicielle du module 1 de la figure 4A dans laquelle I'ensemble des 

programmes d'application A1, A2, An et des fonctions de securite (calcul de condense, 

algorithmes cryptograph iques symetriques tels que DES, triple DES, ou asymetriques tels que 
proposes par RSA) est mis en oeuvre dans le microprocesseur securise 3. 

Les applications nominees ci-dessus et dans la suite de la description A1, A2, An 

35 comprennent au minimum les filtres F1, F2, Fn, et done en particulier les logiciels de 
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traduction des requ&es 6mises par le ou les fournisseurs de services applicatifs FAp faisant 
partie de ('application principale 54 (Figure 8A). 

Le microcontrdleur standard 2 g£re Penvironnement au moyen de differents 
programmes de gestion ou gestionnaires d'interface k savoir ; 


- un gestionnaire 27 de ^interface DTMF 9 ; 

• un gestionnaire 28 d'autres interface, dans Phypoth6se ou le module 1 comporte une 
ou des interfaces autres que celles representees k la figure 2. 

Ainsi, le microprocesseur securise 3 peut piloter les interfaces au moyen de 

15 commandes qui sont interpretees par Pinterpreteur 20 et ex£cutees par le microcontrdleur 
standard 2 grace aux gestionnaires 21-28. 

La figure 4C illustre une seconde configuration logicielle du module 1 de la figure 4A 
dans laquelle une ou plusieurs applications Ax et une ou piusieurs fonctions 
cryptograph iques Sx sont stockees dans une memoire reprogrammable 30a d'un 

20 microprocesseur securis£ 30 d'une carte a micro-circuit 31 . Lorsque la carte 31 est introduite 
dans le lecteur 6, le microprocesseur 30 execute les applications Ax et les fonctions 
cryptographiques Sx, tandis que d'autres applications et fonctions de security peuvent etre 
residentes dans et mises en ceuvre par le microprocesseur securise 3 du module 1. Cest 
ainsi, par exemple, que le microprocesseur 30 de la carte 31 peut assurer une fonction de 

25 signature £lectronique dans Phypoth^se ou le microprocesseur securise 3 n'integre pas un 
processeur de calcul dedi£ (cryptoprocesseur). Reciproquement, si le microprocesseur 
securise 3 integre un cryptoprocesseur, il est egalement possible qu'une application pr£sente 
dans la carte ci micro-circuit 31 fasse appel £ des commandes cryptographiques du module 
1, commandes qui seront executes par le microprocesseur securise 3. 

30 Dans cette seconde configuration, qui pour le reste est identique k celle de la figure 4B, 

I'interpreteur 20 joue vis-a-vis du microprocesseur 30 le meme rtiie que celui qu'il remplit vis- 
a-vis du microprocesseur securise 3. Le module 1 peut ainsi executer des applications 
differentes selon le type de carte 31 k micro-circuit introduit dans le lecteur 6, par exemple : 


10 


5 


- un gestionnaire 21 du lecteur ou interface 6 de carte k micro-circuit; 

- un gestionnaire 22 de ('interface 7 de liaison serie ; 

- un gestionnaire 23 du clavier 5 ; 

- un gestionnaire 24 de ('interface 8 de liaison par infrarouge ; 

- un gestionnaire 25 de Pafficheur 4 ; 

- un gestionnaire 26 de Phorioge 10 et de la source d'alimentation 11; 
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- une authentication de I'utilisateur dans le cadre d'une transaction bancaire 
(consultation de compte, virement de fonds, etc..) effectuee via une ligne telephonique au 
moyen de I'interface DTMF 9 ; 

- une consultation du solde d'un porte-monnaie £lectronique, ou le rechargement de 
5 ce porte-monnaie, k partir du module 1, lorsqu'une carte k micro-circuit 31 remplissant la 

fonction de porte-monnaie est introduite dans le lecteur 6. En outre, le module 1 permet de 
gerer plusieurs cartes porte-monnaie differentes : porte-monnaie bancaire, porte-monnaie 
sp£cifique k une collectivity par exemple ; 

- lecture d'un dossier medical sur une carte m£dicale ; 

10 - lecture de points de fidelity sur une carte dans laquelle des points de fideiite sont 

attribues k un consommateur en fonction d'achats effectues, de sa participation k des 
operations de fideiisation de clientele, etc... 

Le mode d'execution decrit ci-dessus k la Figure 4A ainsi que les configurations 
logicielles presentees dans les Figures 4B et 4C s'appliquent, de maniere analogue, a un 

15 terminal construit autour d'un PC conventionnel equipe en outre du microprocesseur 
securise 3. Dans ce mode d'execution, le microcontr&leur 2 correspond au PC 102 tel qu'il 
est prSsente k la Figure 2A, I'unite de traitement 2a correspond au microprocesseur 102c du 
PC, et les memoires RAM 2b et permanentes 2c correspondent respectivement k la memoire 
RAM 102d et au disque dur 102b. De m&me les entrees / sorties 102a du PC correspondent 

20 aux modules d'interfaces 7, 8 et 12 de la Figure 4A. La connexion entre le microprocesseur 
securise 3 et le PC 102 peut etre une liaison serie ou paraliele, ou bien encore une 
connexion au bus interne du PC, du type PCMCIA, ou une connexion directe sur la carte 
mere du PC. En variante, le microprocesseur securise 3 peut etre integre de manure fixe, ou 
amovible via le connecteur 41 , au clavier du PC. 

25 Dans ce cas, le module logiciel interpreter 20 ainsi que les modules logiciels de 

gestion des peripheriques 21 k 28 sont impiantes et executes sur le PC. L'architecture 
fonctionnelle de ce mode d'execution est equivalente k cede presentee k la Figure 2B, le 
module interpreteur 20 ainsi implants sur le PC assurant le mfime rdle que le module 
interpreteur I de la Figure 2B : il execute les commandes de pilotage des ^changes avec 

30 I'utilisateur refues du logiciel filtre F lui-m&me implants de maniere securise dans le 
microprocesseur 3 (Figure 48) ou la carte k circuit integre 30 (Figure 4C). 

Le schema de la figure 5 illustre un deuxi£me mode d'execution de la deuxifeme forme 
de realisation de ^invention, dans lequel les circuits electroniques du module terminal 1 sont 
organises autour d'un seul microcontrdleur 29 rempla^ant le microcontroleur 2 et le 

35 microprocesseur 3 et pouvant offrir le meme type de protection physique et logique que les 
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microprocesseurs corpus pour les cartes k circuit integre. Ce microcontrfileur g6re I'ensemble 
des moyens d'interfaces 4-9 du module terminal. II comporte une unite de traitement 29a, une 
memoire temporaire (RAM) 29b, une memoire permanente (ROM) 29c et une memoire semi- 
penmanente (EEPROM) 29d permettant le stockage du logicief de traduction. L'unite de 
5 traitement 29a correspond k la fois k l'unite 2a de traitement de donnges permettant le pilotage 
des interfaces et k l'unite 3a de traitement permettant ('execution du logiciel de traduction. De 
m&me que pr&tedemment, le module terminal 1 peut £tre construit autour d'un ordinateur 
personnel PC 102 auquel serait connecte au bus interne un microcontrdleur securise 29 
pilotant ainsi directement l'6cran d'affichage 4 et le clavier 5 du PC. 

10 Dans une variante de realisation, la memoire dans laquelle est stockee le logiciel de 

traduction des requites de haut niveau, memoire volatile de type RAM avec une alimentation de 
sauvegarde ou semi-permanente (EEPROM ou Flash RAM), peut §tre exteme au microcontrdleur 
29. Dans ce cas, le logiciel de traduction peut Stre chiffre et signe, ou protege par un code de type 
MAC ("Message Authentication Code") de manure k assurer k la fois son integrite et sa 

1 5 confidentiality Le logiciel est lu par le microcontrdleur 29, dechiffre puis execute. 

Selon un troisteme mode d'ex&rution, represent^ k la figure 6, de la deuxieme forme 
de realisation de Pinvention, le module terminal 101 est d^pourvu de microprocesseur 
s£curis6 3. Sur cette figure 6, les memes nurrteros de reference qu*k la figure 4A ont 6te 
conserves pour designer les mgmes Elements. Le microcontrdleur 2 pilote Pinterface 6 et le 

20 commutateur-adaptateur 15 pour permettre la connexion du microprocesseur securise 130 
d'une carte k micro-circuit programmable 131 ptesente dans I'interface 6 avec Pinterface de 
liaison externe 7. Dans ce cas, I'ensemble des applications A et des fonctions 
cryptographiques C sont nrtemoris6es dans une memoire semi-permanente 130a (EEPROM 
ou Flash RAM) du microprocesseur s6curis£ 130 de la carte k micro-circuit programmable 

25 131, et mises en oeuvre par ce dernier comme decrit k la figure 4C k propos des applications 
Ax et des fonctions cryptographiques Cx. 

Dans les exemples droits pr£c6demment, dans un but de simplification, le 
microprocesseur 30, 130 de la carte k circuit integte ainsi que le microprocesseur securise 3 
6ventuellement implante dans le module terminal comporte un seul port de communication. 

30 Ceci implique que dans ces exemples, les ^changes entre les differentes entites, k savoir l'unite 
6lectronique 154 (figure 8) contenant I'application principale, le microprocesseur securise 3 et 
le microprocesseur 30, 130 de la carte circuit integte se font k travers le microcontroleur 2 ou 
29 du module terminal. Ces descriptions ne doivent pas Stre considerees comme limitatives : 
d'autres mises en oeuvre peuvent 6tre envisages dans le cadre de la presente invention. En 

35 effet, les microprocesseurs securis^s de carte k circuit integre actuellement disponibles, 
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utilisables pour la carte elle mfime (microprocesseur 30, 130) ou dans le module terminal 
(microprocesseur 3), peuvent comporter deux ports de communication. Differentes formes de 
realisation optimisant les flux de communication sont done aisement envisageables avec ce 
type de microprocesseur. Dans le cas de la figure 4C, par exemple, un des ports de la carte k 
5 circuit int£gr£ 31 peut etre dedie au pilotage de I'interface utilisateur et done relie au 
microcontr6leur 2, I'autre port &ant relie & I'unite electronique comportant I'application 
principale moyennant une adaptation d'interface appropriee. 

Suivant une caracteristique importante de I'invention, un logiciel filtre est implante 
dans la memoire reprogrammable EEPROM assoctee au microprocesseur securise 3 ou 29 
10 du module terminal 1 et/ou au microprocesseur securise 30, 130 de la carte 31, 131. Ce 
logiciel filtre traduit de mantere connue les requites de haut niveau en provenance du 
serveur Sap ou de I'ordinateur personnel PC en sequences de commandes elementaires 
executables par ces microprocesseurs (commandes qui sont notamment definies par la partie 
4 de la norme ISO 7816-4). En outre, suivant invention, ce logiciel filtre traduit ces requetes 
15 de haut niveau en sequences d'^changes de donn6es entre le module terminal 1, 101 et un 
utilisateur via les moyens d'interface tels que I'afficheur 4 et le clavier 5. 

Cette solution offre I'avantage de r£duire considerablement le debit de donnees 
£chang£ entre le module terminal 1, 101 et le serveur Sap ou le PC, mais requiert une 
implantation s£curis£e du logiciel de traduction pour emp£cher que les instructions 
20 envoyees k la carte k micro-circuit soient modifies. 

Ce logiciel filtre fait partie integrante de fa partie du logiciel duplication implantee 
dans le module terminal 1 et/ou la carte 31, 131 et il est done tei£chargeable. 

La figure 7 illustre ['architecture logicielle conventionnelle d'une carte a micro-circuit 
("smart card"). 

25 Les differentes couches de logiciels sont representees par un bloc 43 qui comprend 

une couche logicielle 44 "protocole de communication" permettant de recevoir des 
commandes. Ces commandes sont d6cod£es par une couche logicielle 45 "Interpretation 
commandes APDU" (APDU : "Application Protocol Data Unit" dont le role est d'orienter les 
commandes vers des modules de traitement qui peuvent etre : 

30 - un logiciel 46 de services de gestion de fichiers securises ; 

- un logiciel 47 de services cryptograph iques ; 

- un ou d'autres logiciels duplication 48 

Les modules de traitement 46, 47, 48 s'appuient sur des services de base offerts par le 
systeme d'exploitation 49 de la carte h micro-circuit. 
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La figure 8A illustre ('architecture togicieile d'un systeme de mise en oeuvre de 
transactions securis6es faisant appel k des modules terminaux 1 dotes d'un microprocesseur 
s6curis6 3, confornrtement au mode d'execution de ['invention de la figure 4A. 

Le bloc 51 d^signe les logiciels executes par le microprocesseur securis£ 3 du module 
5 terminal 1, le bloc 52 les logiciels executes par le microcontrdleur 2 ou PC 102 du module 
terminal 1, le bloc 53 les logiciels executes par le microprocesseur 30 d'une carte k micro- 
circuit 31, et le bloc 54 le logiciel principal duplication, ou Fournisseur de services 
applicatifs, implante dans le serveurSap ou un ordinateur personnel PC. 

Le bloc 51 est similaire au bloc 43 de la figure 7, c'est-^-dire que le microprocesseur 
1 0 securise 3 a une architecture semblable k celle d'une carte k circuit integre. Le bloc 51 comprend: 

- un logiciel 60 de protocole de communication. 

- un systeme d 'exploitation 61 

- un bloc 62 representant la partie du logiciel duplication implantee dans le module 
terminal 1, cette partie du logiciel duplication etant essentiellement constitute du logiciel 

15 filtre precite. Oifferents modules logiciels de ce type correspondant k difterentes applications 
peuvent cohabiter dans le microprocesseur securise 3. 

- optionnellement, un logiciel 63 permettant d'assurer I'authentification du 
microcontrdleur standard 2 par le microprocesseur s£curis6 3 et ('authentication du 
microprocesseur s6curis6 3 du module terminal 1 par le microprocesseur 30 de la carte 31, 

20 - un logiciel 64 de gestion de fichier s6curis6, 

- un logiciel 65 de services cryptographiques. 

Le bloc 52 comprend : 
• un logiciel 70 de protocole de communication ; 

- un interpteteur de commandes 71 correspondant au logiciel 20 des figures 4B et 4C ; 
25 - un logiciel d'authentification 72 permettant, en liaison avec le logiciel 63, I'authentification 

du microcontrdleur standard 2 par le microprocesseur securise 3 du module terminal 1 ; 

- des logiciels 73 de gestion des ressources internes du microcontrdleur 2 ; 

- des logiciels 74 de pilotage des interfaces avec I'utilisateur (gestionnaires 23 et 25 de 
I'ecran 4 et du clavier 5) ; 

30 - des logiciels 75 de pilotage des interfaces de communication 7, 8 et 9 (gestionnaires 22, 
24, 27) ; 

Enfin, le bloc 53 est similaire au bloc 43, mais ne comporte pas, dans I'exemple decrit 
par la figure 8A, de logiciel d'application ou filtre. II comprend : 

- un logiciel 80 de protocole de communication, 

35 - un logiciel 81 d'interptetation de commandes APDU, 
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- un logiciel 82 de services de gestion de fichier s6curise (contr6le du PIN par exemple), 

- un logiciel 83 de services cryptograph iques (calculs cryptographiques symetriques k cl£s 
secretes ou asymetriques, k cl<§s publiques et cl6s privies, etc..) permettant, entre autres, 
d'assurer, en liaison avec le logiciel 63, Pauthentification du microprocesseur s£curis6 3 du 

5 module terminal 1 par le microprocesseur 30 de la carte 31, 

- le systeme d'exploitation 84 du microprocesseur 30 de la carte 31 . 

Le protocole de communication 60, 70, 80 permet de g£ner les ^changes de donnees entre: 

- le microprocesseur 30 de la carte 31 et le microcontr6leur standard 2 ou PC 102 du 
module terminal 1 ; 

10 - le microprocesseur s£curis£ 3 et le microcontrfileur 2 du module terminal 1 ; 

- le microprocesseur securise 3 du module terminal 1 et le microprocesseur 30 de la carte 31 . 

La figure 8B est une vue similaire k la figure 8A illustrant ['architecture logicielle du 
systeme dans le cas ou le module terminal 101 ne comporte pas le microprocesseur securise 
3, conformement au troisteme mode d'execution du deuxi£me mode de realisation de 

1 5 ('invention de la figure 6. 

Sur la figure 8B, le bloc 152 d«§signe les logiciels executes par le microcontr6leur 2 du 
module terminal 101, le bloc 153 les logiciels executes par le microprocesseur 130 d'une 
carte k micro-circuit programmable 131, et le bloc 154 le logiciel principal duplication 
implants dans le serveur Sap ou un ordinateur'personnel PC. 

20 Le bloc 152 comprend les memes logiciels 70, 71 et 73 k 75 que le bloc 52 de la 

figure 8A, et un bloc 76 qui est un logiciel d'authentification du microcontrfileur standard 2 
du module terminal 101 vis-^-vis du microprocesseur 130 de la carte 131 . 

Le bloc 153 relatif au microprocesseur 130 de la carte 131 comprend les logiciels 62 
et 80 k 84 des blocs 51 et 53 de la figure 8A, ainsi qu'un logiciel 77 permettant, en liaison 

25 avec le logiciel. 76, d'assurer Pauthentification du microcontrdleur standard 2 du module 
terminal 101 vis-^-vis du microprocesseur 130 tie la carte 131. 

A la difference d'un systeme conventionnel, dans le systeme de transaction securisee 
selon Pinvention, le logiciel filtre 62 qui traduit les requites de haut niveau de Papplication 
en commandes elementaires executables par une carte k micro-circuit est implante dans 

30 Penvironnement utilisateur securise, c'est-i-dire soit dans le module terminal 1 (pour les 

applications A1, A2 An des modes d'execution des figures 4A-4C et 5), soit dans une carte 

31, 131 k mSmoire semi-permanente utilisable avec le module terminal 1, 101 (pour les 
applications Ax du mode de realisation de la figure 4C et pour toutes les applications du 
mode de realisation de la figure 6). 
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Outre sa fonction de gestion d'une carte k micro-circuit, ce logiciel fiitre 62 g£re les 
interactions avec I'utilisateur, c'est-i-dire les sequences d'echange de donnees entre un 
utilisateuret le module terminal qui sont requises dans le cadre d'une application, ^changes 
qui ont lieu par I'intermediaire des moyens d'interface, k savoir I'ecran 4 et le clavier 5. II est 
5 k noter que ('invention n'est pas limine k ('utilisation d'un ecran et d'un clavier comme 
interfaces avec I'utilisateur et que tout autre type d'interface, par exemple vocale, pr&entant 
I'ergonomie requise, pourrait convenir. 

Grace k Pimplantation sScurisee du logiciel fiitre 62 dans le microprocesseur securis£ 
3 ou 29 du module terminal 1 ou le microprocesseur 30, 130 de la carte k micro-circuit 31, 
10 131, la securite des transactions est assume. En effet, les des et regies necessaires pour 
acceder k des fichiers de la carte k micro-circuit 31, 131 sont contenues dans le logiciel de 
traduction 62 et sont done inaccessibles k des tiers. 

Les fonctions remplies par le logiciel fiitre 62 seront illustrees ci-apr6s en prenant 
Pexemple d'une application visant le commerce Slectronique. L'application met en ceuvre 
1 5 les entites suivantes : 

• un acheteur 

• un commergant, 

• une banque. 

Le commergant dispose d'un serveur de commerce 6lectronique Sap (serveur Web) 
20 accessible depuis le reseau Internet. Les acheteurs sont 6quipes de: 

• un ordinateur PC permettant d'acc^der au serveur Sap de commerce 
electronique, et grace auquel I'acheteur peut consulter un catalogue de marchandises. 

• une carte k circuit int£gr£ 31 d6iivr£e par la banque et dont le microprocesseur 
30 contient une cl6 priv^e, mais ne dispose pas de capacity cryptographiques permettant 

25 d'effectuer une signature, 

• un module terminal 1 selon le mode de realisation de la figure 4A, dote d'un 
microcontrdleur standard 2, d'un microprocesseur s6curise 3 disposant de capacity 
cryptographiques permettant la signature d'un message, d'un clavier 5, d'un afficheur 4, d'une 
interface carte k circuit int6gn§ 6 et d'une interface s6rie 7 pour sa connexion k un ordinateur PC. 

30 Les principes de fonctionnement sont les suivants : la transaction est signee par le 

module terminal 1 k I'aide d'une cl£ privee d&enue par la carte 31. Cette cl6 privee est 
protegee par un code porteur confidentiel (PIN) que I'acheteur doit saisir en milieu securise, 
donc sur le terminal 1, et par une authentication prealable du terminal 1 par la carte 31 k 
I'aide d'une cle secrete Kauth. De plus la cl6 privee est transmise de mantere chiffree (par une 
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cl6 Kchif) de manure k &ablir un canal de communication securise entre le microprocesseur 
30 de la carte k circuit integree 31 et le microprocesseur securise 3 du terminal 1 . 

La figure 9 illustre les ^changes entre les differentes entites : 

a. I'acheteur constitue sa commande sur I'ordinateur PC, 
5 b. I'ordinateur PC Slabore la transaction k faire signer par I'acheteur (reference article, 

prix) etdemande la signature de cette transaction au module terminal 1, 

c le module terminal v^rifie I'origine de la demande de signature puis sollicite la 
saisie du code PIN par affichage d'un message "saisie PIN" sur son afficheur 4, 

d. I'acheteur saisit son code porteur (code PIN) sur le clavier 5 du module terminal 1, 
10 e. le PIN est envoye par le module terminal 1 k la carte 31 pour verification. Cette 

verification 6tant positive, elle provoque la levee d'une de deux conditions d'acc^s k la 
lecture de la cle privee, 

f. le module terminal 1 affiche la transaction sur son afficheur 4, 

g. I'acheteur donne son accord, par appui sur une touche "validation " du clavier 5 du 
15 module terminal 1, 

h. le module terminal 1 soumet une demande d'authentification externe k la carte 31. 
Cette authentification externe permet au microprocesseur securise 3 du module terminal 1 
de s'authentifier vis-^-vis du microprocesseur 30 de la carte 31 et de lever ainsi la deuxteme 
protection d'acc£s k la cle privee. Cette authentification se fait en mode challenge/r^ponse 

20 sur la base d'un secret., Kauth, partag£ par le module terminal 1 et la carte 31, 

L le module terminal 1 envoie une demande de lecture de c!6 privee k la carte 31, 
j. toutes les conditions d'acces etant remplies, la carte 31 accepte la demande de 

lecture, et renvoie la cle privee, chiffrfe par une cl6 secrete, Kchif, partagee par la carte 31 et 

le module terminal 1, 

25 k. le module terminal 1 dechiffre la cle privee, signe la transaction au moyen de la cle 

privee, d&ruit la cl£ privee, se d£connecte de la carte 31 et envoie e la transaction signee k 

I'ordinateur PC qui la transmet au serveur S. 

Cet exemple peut 6tre transpose aisement k une transaction electronique effectuee 

sans ordinateur PC, le module terminal 1 se connectant directement k un serveur Sap par 
30 une liaison modem (figure 3), I'acheteur entrant la commande (reference produit) sur le 

module terminal 1. 

II est k noter que I'authentification du microprocesseur securise 3 par la carte peut 
aussi §tre effectu6 k travers la commande de lecture de cle privee en lui associant un code 
d'authentification MAC (Message Authentification Code) calcule au moyen d'une cle secrete. 
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Cet exemple montre que le logiciel filtre 62 perrnet de traduire une requete de haut 
niveau "demande de signature de transaction" en une multitude de requites yiementaires 
adress^es aux differentes interfaces du module terminal 1, a savoir I 1 interface 6 avec la carte 
& circuit integre 31, I'interface afficheur 4, ['interface clavier 5, ('interface de connexion k 
5 Pordinateur PC ou au serveur Sap. 

Un tel logiciel filtre de traduction a un r6le d'ecran, de filtre entre le monde exterieur, 
c'est k dire les applications, et les p£ripheriques qu'il g£re. 

II ameliore la security offerte du fait que : 

1 . il impose un s£quencement aux ordres 6l6mentaires envoy^s. Par exemple, dans le cas 
1 0 illustre ci-dessus, il impose que la transaction soit valid^e par I'utilisateur avant d'etre signee. 

2. il dispose seul des param&res secrets permettant de g£n6rer et d'authentifier ces ordres 
yiymentaires, Ainsi il dispose seul des des d'authentification et de chiffrement permettant de 
lire et dechiffrer la cle priv^e. 

Lorsque le logiciel filtre est execute dans le microprocesseur s6curis£ 3 du module 
15 terminal 1, ces proprietes permettent d'imposer une politique d'acc^s k la carte 31, politique 
qui n'est pas toujours complement imposee par la carte elle-myme, ou d'etendre les 
capacites d'une carte (capacity de signature d6legu6e au module terminal, utilisation dans un 
contexte non pr6vu lors de son d£ploiement initial). 

Les avantages offerts en terme de s£curit6 par Tex^cution du logiciel filtre dans le 
20 microprocesseur securis6 du module terminal ou dans celui de la carte k circuit integrS ne 
sont possibles que parce que le logiciel s'exycute dans un environnement securise 
permettant d ! assurer que : 

• les secrets contenus par le logiciel filtre ne sont pas accessible^ du fait qu'iis sont 
memorises au sein du microprocesseur securis6 3, 29, 30 ou 1 30, 
25 • la confidentiality et Pintegrite du logiciel filtre sont preserves, du fait que ce 

logiciel est m£moris£ dans la microprocesseur securise 3, 29, 30 ou 1 30. 

Dans le cas ou le module terminal 1 est un produit dydie, disposant de ses propres 
interfaces, afficheur 4 et clavier 5, 1'objectif de security est atteint grSce au fait que le logiciel 
pilotant les ^changes de donnees avec I'utilisateur ne peut Stre modifiy, dans la mesure ou il 
30 est stocks de manure definitive dans la m^moire permanente 2c du microcontrfileur 2 ou de 
mani^re s£curis£e dans le microcontr6leur 29. L'utilisateur peut ainsi valider en toute 
confiance le contenu de sa transaction grace b I'afficheur 4 et au clavier 5, rendant optionnel 
la necessity de verifier Pidentite de ('application ou Porigine et I'int6grit6 des requfites. 

D'autres m^canismes peuvent encore amyiiorer le niveau de security de la chaine de 
35 confiance entre le microprocesseur securisy de la carte & circuit intygry, Peventuel 
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microprocesseur securise du module terminal, le microcontrflleur standard ou le PC du 
module terminal et I'utilisateur. Ces mecanismes sont les suivants : 

A) telechargement securise du logiciel filtre ; 

B) authentification du microcontrflleur standard par le microprocesseur securise ou, ce 
5 qui est equivalent mais mieux adapte dans le cas d'un mode d'execution du terminal autour 

d'un PC, authentification du module logiciel interpreter I (20) par le logiciel filtre F (62), 
et/ou etablissement d'un canal de communication securisee entre ces deux microprocesseurs 
ou les logiciels I et F, 

C) protection d'un secret par le microcontrdleur standard , 

10 D) authentification mutuelle et etablissement d'un canal de communication securise 

entre le microprocesseur securise de la carte k circuit integre et le microprocesseur securise 
du module terminal, 

E) authentification du module terminal, et eventuellement du couple module terminal- 
carte, 

15 F) authentification.de ia carte k micro-circuit par le module terminal. 

A) Telechargement securise du logiciel filtre 

L'organigramme de la figure 10 illustre le processus de telechargement d'un 
programme duplication (logiciel filtre) dans le microprocesseur securise 3 ou 29 du 
module 1 ou le microprocesseur securise 30, 130, d'une carte 31, 131 presente dans le 

20 lecteur 6. Ce telechargement peut etre effectue k partir d'un serveur Sap via, par exemple, 
I'ordinateur personnel PC et ('interface 7 de liaison exteme ou ('interface 8 de liaison 
infrarouge, ou directement au moyen d'une liaison teiephonique grace k I'interface 9 de 
liaison par DTMF. Le telechargement peut egaiement Stre effectue dans le microprocesseur 
securise 3 ou 29 (si le module terminal en est equipe) k partir d'une carte k micro-circuit 

25 introduite dans le lecteur 6. 

A Tetape 32 f la zone de la memoire 3d allouee au programme d'application a recevoir 
est vide et le microprocesseur 3 est en attente du chargement du programme d'application a 
la suite d'une requete de chargement. 

L'etape suivante 33 correspond k une procedure d'authentification par le 

30 microprocesseur 3 de Pentite appeiee k telecharger le programme d'application (Emetteur). 
Cette procedure d'authentification peut faire appel, par exemple, k des mecanismes de 
chiffrement bien connus des special istes de la technique, par exemple des mecanismes 
symetriques k c\es secretes partagees ou des mecanismes asymetriques k cie privee et cie 
publique. 
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L'&ape 34 est un test visant k determiner si la procedure d'authentification a reussi : 
dans la negative, le message "acc£s refuse" est affichS sur I'dcran 4 (6tape 42) et le 
programme retourne k I'&ape 32; dans I 'affirmative, le processus de chargement du 
programme duplication commence k I'dape 35. 
5 L'6tape 36 correspond au stockage dans la mSmoire EEPROM 3d des trames .de 

donn£es transmises par I'entit^ assurant le telechargement. 

L'etape 37 est un test pour determiner si le t£i6chargement est achev6 : dans la negative, 
le programme de t6l6chargement revient k T&ape 36 et le tetechargement se poursuit ; dans 
('affirmative, il est precede k l'etape 38 k une verification de I f int6grit6 des donn^es regues par 

10 le microprocesseur 3. A cet effet, un code d'authentification de message (MAC) peut §tre 
associe au programme telecharg£ pour permettre de verifier non seulement son integrite, mais 
§galement son origine. Le MAC peut etre produit en utilisant un mecanisme de cryptographie 
sym&rique (DES en mode chains CBQ. La verification de I'origine et de l'int<§grite peut aussi 
etre realisee k I'aide d'un mecanisme de cryptographie asym&rique : un condense du logiciel 

15 tel£charge est signe par I'emetteur k Taide de sa cle priv6e ; le microprocesseur securise 3 
verifie ensuite la signature k I'aide de la cle publique de I'emetteur, 

II est £ noter que dans ce dernier exemple, la cle publique par principe ne necessite 
pas de rester confidentielle. Cependant la s&rurite apportee par le microprocesseur assure 
I'integrite du logiciel, empSchant un fraudeur de modifier le logiciel pour supprimer la 

20 verification de signature ou simplement de substituer k la cl6 publique initialement prevue 
une cl£ publique pour laquelle il connaitrait la c!6 priv£e assoctee. 

Si d'apr£s le test 39, il s'av£re que les donn^es re?ues sont correctes, un drapeau 
indiquant que le programme duplication re?u est valid£ est 6labor6 k l'etape 40. Dans le 
cas contraire, le programme de telechargement revient k l'etape 32 de depart. 

25 Ce processus de chargement du logiciel duplication, done du logiciel filtre, dans la 

memoire reprogrammable securis£e (3d, 30a, 130a suivant le mode de realisation), 
comporte des mecanismes permettant de cdnfirmer I'origine et ('integrity des donn£es revues 
de I'emetteur du logiciel. Ceci permet d'interdire le telechargernent par un fraudeur d'un 
logiciel filtre qui serait susceptible de mettre en ceuvre des transactions dans le module 

30 terminal 1, 101 k I'insu de I'utilisateur. 

B) Authentification du module logiciel interpreteur I, 20, 71 par le logiciel filtre F, 62 
ou, ce qui est equivalent dans le mode d'execution correspondant, authentification du 
microcontrdleur standard 2 par le microprocesseur securis6, et/ou etablissement d'un 
canal de communication securise entre ces deux logiciels ou ces deux microprocesseurs. 
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Pour qu'un utilisateur puisse avoir une totale confiance dans le module terminal au 
moyen duquel il effectue des transactions, il est necessaire : 

- d'authentifier les donnees transmises du logiciel interpreteur 20, 71 au 
microprocesseur securis^ 3, 30 ou 130 executant le logiciel filtre ; 
5 - d'assurer que les donnees transmises par le logiciel filtre pour gtre affichees par 

Tintermediaire du logiciel interpreteur du module terminal 1, 101 possede par I'utilisateur ne 
peuvent I'etre que par celui-ci\ 

Lorsque les moyens de pilotage des ^changes de donnees avec I'utilisateur, c'est k dire 
le logiciel interpreteur 20, 71, sont implants de maniere fixe et non modifiable dans le 
10 module terminal 1,101, comme par exemple dans la memoire ROM 2c du microcontr6leur 
standard 2, ('authentication du module logiciel est equivaiente a I'authentification du 
microcontrdleur. 

De mgme, lorsque le logiciel filtre est implants de manure k ne pas pouvoir etre 
modifie par une personne non autorisee, dans des moyens de traitement securises tels que le 
15 microprocesseur s£curis£ 3, la carte k circuit integre ou bien le serveur securise Ssec, une 
authentication effectuee par ces moyens securises est equivaiente k une authentification 
effectue par le logiciel filtre lui-m£me. 

Dans la description qui suit, nous decrirons les mecanismes d'authentification des 
moyens logiciels de pilotage des interfaces ou logiciel interpreteur 20, 71 par le logiciel filtre. 
20 Differentes solutions permettent de remplir ces conditions. 

Une premiere solution consiste k chiffrer toutes les donnees £changees entre le le 
logiciel interpreteur 20, 71 et le logiciel filtre. 

Une deuxi£rne solution consiste k faire proceder k ^authentication du logiciel 
interpreteur 20, 71 par le le logiciel filtre et/ou k etablir un canal de communication securise 
25 entre ces deux logiciels. 

Ces deux solutions impliquent necessairement qu'au moins un parametre secret connu 
du logiciel filtre F, 62, soit stocke dans le logiciel interpreteur 20, 71 . 

Selon la deuxieme solution, le logiciel filtre F, 62 authentifie le logiciel interpreteur 20, 
71, selon un processus conventionnel d'authentification, sur la base d'une information 
30 transmise par le logiciel interpreteur 20, 71, et combinee avec le parametre secret. Au 
niveau du logiciel interpreteur 20, 71, cette procedure d'authentification est mise en oeuvre 
par le logiciel 72 (figure 8A) ou le logiciel 76 (figure 8B), suivant la forme de realisation du 
module terminal. 
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Ce mecanisme d'authentification peut egalement s'appliquer aux messages echanges 
entre Ies deux logiciels pour construire des codes d'authentification des messages permettant 
de garantir I'origine et I'integrite de chaque message transmis. 

Dans le cas du mode d'execution decrit k la Figure 4A, cette solution requiert 
5 cependant que, de preference, une protection physique de la liaison entre Ies deux 
microprocesseurs soit assume pour interdire k un fraudeur de lire Ies donnees echangees, et 
en particulier le code d* identification personnel (PIN) de la carte que Putilisateur peut etre 
amene k introduire via le clavier 5 pour la mise en oeuvre des transactions. 

C) Protection d'un parametre secret par le microcontroleur standard 2 

10 La description precedente montre la necessite de stocker au moins un parametre secret 

dans le logiciel interpreter. Le mode d'execution du terminal k partir d'un PC, dans lequel 
le logiciel interpreter est execute sur le PC iui-meme, offre done de par la securite limine 
du PC un degre de securite limite bien que suffisant pour emp^cher un virus de se substituer 
au logiciel interpreter. Un degre de securite sup£rieur est obtenu en implantant le logiciel 

15 interpreter dans la ROM 2c du microcontrdleur standard 2. Pour ameiiorer la security le 
parametre secret du microcontrdleur 2 pourra Stre stocke dans ia memoire temporaire, et 
cela k la fabrication du produit ou, eventuellement, lors de Pinsertion du microprocesseur 
securise 3 s'il est amovible, ou d'une carte k circuit integre. Cette operation a pour but 
d'&abiir une confiance entre Ies deux microprocesseurs. Toute precaution utile doit etre 

20 prise lors de cette operation pour s'assurer de I'authenticite du microcontrdleur 2 (operation 
effectu^e en usine, operation protegee par des des dites de transport elles-rngmes stockees 
dans la memoire temporaire du microcontrdleur 2 en usine, et dont la connaissance 
conditionne I'operation d'initialisation dudit parametre secret). En outre des mecanismes 
conventionnejs de detection d' intrusion (contacts...) seront mis en place, pour provoquer 

25 Teffacement de la memoire temporaire en cas d'intrusion (coupure alimentation...). 

D) Authentification mutuelle et etablissement d'un canal de communication securise 
entre le microprocesseur de la carte h circuit integr£ et le microprocesseur sec u rise du 
module terminal 

Cette authentification mutuelle et Tetablissement du canal de communication 
30 securisee sont realises par la mise en ceuvre de mecanismes identiques k ceux utilises entre 
le microcontrdleur standard 2 et le microprocesseur securise executant le logiciel filtre 
comme decrit au point B) ci-dessus. 

E) Authentification du module terminal 

II est important de se premunir vis-ci-vis de toute attaque contre I'ensemble clavier 5, 
35 afficheur 4, microprocesseur securise 3, visant par exemple k effectuer des contrefagons de 
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module terminal , k substituer un module terminal par un module terminal contrefait dans le 
but de recuperer des informations saisies par I'utilisateur (espionnage clavier), d'acceder aux 
secrets d'une carte k circuit integrS, d'effectuer des fausses signatures. 

Pour cela, il pourra Stre ajoute un mScanisme permettant k I'utilisateur d'authentifier 
5 son terminal. 

Cet objectif est atteint grace k un processus de personnalisation automatique. 
Authentification du module terminal seul 

La personnalisation peut consister en le calcul d'un mot de passe facile k se rappeler 
g£n6re et affiche par le terminal en fonction des param&tres secrets contenus par le ou les 

10 microprocesseurs du terminal, lorsque I'utilisateur introduit un PIN. Si le terminal comporte 
par exemple deux microprocesseurs, le mot de passe est stocke dans le microprocesseur 
securise, chiffre par le PIN et une cle secrete X, puis transmis au microcontrdleur 2 pour 
dtchiffrement avec la cl6 X stockee 6galement dans le microcontrdleur 2 et le PIN introduit 
par I'utilisateur. Ce mecanisme vise a se prtmunir centre la substitution de Tun des deux 

1 5 microprocesseurs. 

Le meme principe peut §tre appliqut k un couple carte/terminal k chaque fois qu'une 
carte k micro-circuit est utilis^e avec le module terminal. La personnalisation peut consister 
par exemple en le calcul, au moyen du logiciel de traduction, d'un mot de passe base sur 
une information secrete contenue dans le microprocesseur s6curis6 de la carte et d'une ou 

20 plusieurs informations secretes contenues dans module terminal. Le mgme principe que 
celui decrit ci-dessus peut etre utilise pour calculer le mot de passe. Ce mot de passe, genere 
lors de la premiere utilisation du module terminal en conjonction avec la carte et connu de 
I'utilisateur, est affiche sur I'Scran 4 lors des utilisations subsequentes du module terminal 
avec la carte. L'utilisateur peut ainsi le verifier et avoir ainsi Passurance que le terminal en sa 

25 possession, constitu6 du module terminal coupl£ k la carte, est bien authentique, 
F) Authentification de la carte h micro-circuit par le module terminal 
Pour accroltre encore la s6curit6 du systeme de transaction suivant ('invention, un 
processus conventionnel d'authentification peut §tre mis en oeuvre afin d'assurer 
('authentification par le module terminal 1, 101 de la carte k micro-circuit utilisee. Un tel 

30 processus d'authentification permet notamment d'eviter que le numero d'identification 
personnel (PIN) de I'utilisateur, que celui-ci introduit dans le module 1, 101 par le clavier 5 
pour ex^cuter une transaction s6curis£e, soit capture par une carte falsifiee qui aurait et§ 
substitute par un fraudeur k la carte authentique de I'utilisateur puis que ce fraudeur 
r6cup6rerait pour lire le PIN sur la carte falsifiee. L'authentification peut, par exemple, fitre 

35 effectuSe par un mecanisme classique de type d6fi / rtponse au moyen d'un secret partage 
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entre la carte et le module terminal en utilisant une cryptographie synrtetrique ou bien, 
comme cela a dejci ete decrit pr£c6demment, au moyen d'une cle privee stockee par la carte 
permettant le chiffrement du defi ou challenge k I'aide d'un algorithme asymetrique, le 
module terminal v^rifiant la teponse k I'aide de sa cl6 publique. 
5 L'architecture du systeme de transaction ainsi que les mecanismes de securisation 

dScrits ci-dessus conferent une tr6s grande securite aux transactions effectu£es au moyen du 
module terminal 1, 101. 

Ce module terminal permet : 

- grace au clavier 5, k PScran 4 et k la protection des donnees echangees avec 
10 I'utilisateur, d'etendre la nature des services teellement securis^s que peut foumir une carte k 

micro-circuit; 

- d'utiliser la carte dans le contexte d'un environnement non s6curis£ (ordinateur 
personnel PC susceptible d'etre affecte par des virus ou programmes pirates), en I'isolant 
hermetiquement de cet environnement grace k une architecture logicielle et/ou materielle 

15 qui contrdle strictement I'acc6s k la carte, c'est k dire qui contrdle les commandes envoyees 
aux fonctions cryptographiques contenues dans la carte. 

Le module terminal peut revgtir differentes formes telles que : 

• un lecteur de carte k circuit integte, connectable k un ordinateur via differentes 
interfaces (PCMCIA...) ou non (connexion k un serveur via modem uniquement) ; 

20 • un ordinateur (PC) dont les interfaces utilisateur sont constitutes par I'ecran et le 

clavier du PC, et qui comporte un lecteur de carte k circuit int6gr6. Ce PC inclura des 
rnoyens logiciels et / ou materiels (tels qu'un second microprocesseur securise, le 
rnicrocontrdleur standard 6tant constitue par le PC) pour assurer I'integrite et la 
confidentiality du logiciel filtre. Par ordinateur on entend un ordinateur de type PC, mais 

25 6galement un PDA (* Personal Digital Assistant ' ou Assistant NumSrique Personnel) ; 

• un clavier, 6ventuellement muni d'un £cran d'affichage LCD, dans lequel est 
integte un microprocesseur s6curis6 et une interface carte k circuit integte ; 

• un telephone muni 6ventuellement d'un afficheur, dans lequel est integte un 
microprocesseur s6curis£ et une interface carte k circuit integte ; 

30 • un d£codeur (set-top box) de teseau cable de TV integrant un lecteur ce carte k 

circuit int6gr6 connects a un poste de television, le poste de television, un clavier ou 
eventuellement la tetecommande associe au decodeur ou k la television servant de 
rnoyens d'interface avec I'utilisateur ; 

• plus g6n6ralement tout equipement s6curisable par ('integration d'un 
35 microprocesseur s<§curis6 dans lequel pourra etre installee une application dite sensible, 
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ou par integration d'une interface carte k circuit integr^ permettant le pilotage dudit 
<§quipement par une application deportee dans une carte k circuit integral. J 

L'ensemble de la description pr<§a§dente decrit un terminal destine k gtre utilise 
avec une carte k circuit int«§gr<§ ou "smart card". La carte k laquelle il est fait reference est 
5 en fait un outil permettant la mise en oeuvre de fonctions cryptographiques et 
personnalise par rapport k un utilisateur au moyen d'au moins un secret. II est evident 
que I'objet de invention ne se limite pas k un outil de forme donnee tel que celui de la 
carte k circuit integrS. (-'invention couvre aussi la mise en oeuvre de dispositifs personnels 
de s^curite pouvant offrir des fonctions Squivalentes k celle d'une carte k circuit integral 
10 mais pr&entes sous une forme differente, tels que les produits * i Button * Java Ring * 
ou jeton (* token *). 
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REVENDICATIONS 

1. Terminal pour la mise en ceuvre, par un utilisateur, de transactions 6lectroniques 
s<§curis6es en liaison avec au moins une application implantge sur une unite 6lectronique, 
ledit terminal comprenant : 

- un module terminal comportant au moins : 

5 * des premiers moyens d'interface avec ladite application pour en recevoir des 

requites relatives auxdites transactions, 

* des deuxtemes moyens d'interface avec ledit utilisateur, 

* des troistemes moyens d'interface avec un dispositif personnel de s^curite, 

* des premiers moyens de traitement de donnees comprenant au moins des premiers 
1 0 moyens logiciels de pilotage desdits moyens d'interface, et 

- un dispositif personnel de securite comportant au moins des deuxtemes moyens de 
traitement de donnees securis^s comprenant au moins des deuxiemes moyens logiciels 
d'ex^cution de commandes £l£mentaires et des moyens d'execution de calculs cryptograph iques, 

caracterise en ce que : 

15 - ledit terminal (1, 31 ; 101, 131) est adapte pour recevoir lesdites requfites de ladite 

application (Fap) implantee sur la dite unite Slectronique (Sap ; PC) sous la forme de requites 
de haut niveau independantes dudit dispositif personnel de securite, 

- Tun au moins dudit module terminal (1; 101) et dudit dispositif personnel de securite 
comprend : 

20 * au moins une nrtemoire reprogrammable (3d ; 30a ; 102b ; 130a ; Ssec) de 

stockage d'au moins un logiciel filtre (F, 62), traduisant lesdites requ&es de haut niveau en au 
moins Tune de : 

(i) au moins une. commande elementaire ou une sequence de commandes 
6l6mentaires exScutables par lesdits deuxiemes moyens logiciels (80-84) desdits deuxiemes 

25 moyens de traitement de donnees (30 ; 1 30), ou 

(ii) au moins une sequence d'£change de donnees entre ledit module terminal (1 ; 101) 
et ledit utilisateur via lesdits seconds moyens d'interface (4, 5), executables par lesdits premiers 
moyens logiciels (I, 20, 71 ) desdits premiers moyens de traitement de donnees (2 ; 29 ; 1 02), 

* des moyens de protection dudit logiciel filtre (F, 62), pour empgcher toute 
30 lecture et/ou modification dudit logiciel filtre par une entite non autorisee, et 

- I'un au moins desdits premiers et deuxiemes moyens de traitement de donnees (3 ; 29 
, 30 ; 102 ; 130 ; Ssec) comprend un dispositif de traitement de donnees pour I'ex^cution 
dudit logiciel filtre (F, 62). 
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2. Terminal selon la revendication 1, caracterise en ce que ledit dispositif d'execution 
du logiciel filtre comprend des premiers moyens d'identification et /ou d'authentification de 
ladite application (Fap) implantee dans ladite unite eiectronique (Sap; PC) ou de I'origine 
desdites requ&es emises par ladite application. 
5 3. Terminal selon la revendications 2, caracterise en. ce que ledit dispositif de 

traitement de donnees pour Pex<§cution dudit logiciel filtre (F, 62) comprend des moyens de 
verification de hntegrite des donnees revues de ladite application (Fap). 

4. Terminal selon Tune quelconque des revendications 1 h 3, caracterise en ce que ledit 
dispositif de traitement de donnees pour I'execution dudit logiciel filtre (F, 62) comprend des 

10 moyens centralises (Ssec) de contr6le des conditions d'utilisation des sen/ices du dispositif 
personnel de security (31) en fonction de ladite application (Fap) et/ou de i'utilisateur. 

5. Terminal selon Tune quelconque des revendications 1 k 4, caracterise en ce que ledit 
dispositif de traitement de donnees pour I'execution dudit logiciel filtre (F, 62) comprend : 

-des moyens pour commander le chargement securise dudit logiciel filtre dans ladite 
15 m£moire programmable, via Tun desdits premiers ou troistemes moyens d'interface, k partir 
d'une entite exterieure audit module, et 

- des premiers moyens de contr6le d'accfcs pour n'autoriser ledit chargement dudit 
logiciel filtre qu'en reponse k au moins une condition predefinie. 

6. Terminal selon i'une quelconque des revendications 1 k 5, caracterise en ce qu'il 
20 comprend des deuxi£mes moyens d'authentification desdits premiers moyens de traitement de 

donnees (2 ; 3 ; 29 ; Ssec) par lesdits deuxtemes moyens de traitement de donnees (30 ; 130). 

7. Terminal selon Tune quelconque des revendications 1 k 6, caracterise en ce qu'il 
comprend des troisfemes moyens d'authentification desdits deuxiemes moyens de traitement 
de donnees (30 ; 1 30) par lesdits premiers moyens de traitement de donnees (3 ; 29). 

25 8. Terminal selon i'une quelconque des revendications 6 et 7, caracterise en ce qu'il 

comprend un premier canal de communication (6) entre lesdits premiers (2 ; 3 ; 29) et 
deuxiemes (30 ; 130) moyens de traitement de donnees et des premiers moyens de 
securisation dudit premier canal de communication. 

9. Terminal selon Tune quelconque des revendications 1 k 8, caracterise en ce qu'il 
30 comprend des quatriemes moyens d'authentification dudit module terminal (1 ; 101) par 

ledit utilisateur, independamment dudit dispositif personnel desecurite (31 ; 131). 

10. Terminal selon la revendication 9, caracterise en ce que lesdits quatriemes moyens 
d'authentification comprennent des moyens de calcul, par lesdits premiers moyens de 
traitement de donnees (2 ; 3 ; 29), et de presentation audit utilisateur, via lesdits deuxiemes 

35 moyens d'interface (4), d'un mot de passe connu dudit utilisateur et calcuie sur la base d'au 
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moins un premier parametre secret stocke dans lesdits premiers moyens de traitement de 
donnees (2 ; 3 ; 29). 

1 1 . Terminal selon Tune quelconque des revendications 1^10, caract^rise en ce qu'il 
comprend des cinquiemes moyens d'authentification conjointe dudit module terminal (1 ; 
5 1 01 ) et dudit dispositif personnel de security (31 ; 131) par ledit utilisateur. 

1.2. Terminal selon la revendication 11, caracterise en ce que lesdits cinquiemes 
moyens d'authentification comprennent des moyens de calcul, par ledit dispositif 
d'ex&rution dudit logiciel filtre (3 ; 29 ; 31 ; 131), et de presentation audit utilisateur, via 
lesdits deuxtemes moyens d'interface (4), d'un mot de passe connu dudit utilisateur et 
10 calculi sur la base d'au moins un deuxteme et un troisieme parametres secrets stockes en 
memoire respectivement dans lesdits premiers (2 ; 3 ; 29) et deuxiemes (30 ; 1 30) moyens de 
traitement de donnees. 

13. Terminal selon Tune quelconque des revendications 1^12, caracterise en ce que 
ledit module terminal (1) comporte ladite memoire programmable (3d) pour le chargement 

15 et le stockage.dudit logiciel filtre (F, 62). 

14. Terminal selon la revendication 13, caracterise en ce que ledit logiciel filtre (F, 62) 
g£n£re des premieres commandes pour la mise en oeuvre de ladite sequence d'echanges de 
donnees entre ledit module terminal (1) et ledit utilisateur, et en ce que lesdits premiers 
moyens de traitement de donnees comprennent un premier microprocesseur (2 ; 102) de 

20 pilotage desdits moyens d'interface (4-9) programme grace auxdits premiers moyens logiciels 
(20, 71) de pilotage desdits moyens d'interface pour executer lesdites premieres commandes 
gen^rees par ledit logiciel filtre (F, 62), et un deuxteme microprocesseur securise (3) du type 
pour carte k circuit integre dispose dans ledit module terminal et comportant ladite memoire 
programmable (3d), ledit second microprocesseur (3) executant ledit logiciel filtre (F, 62) 

25 pour le pilotage de ladite sequence d'echanges de donnees au moyen desdites premieres 
commandes tfansmises audit premier microprocesseur (2) et pour Papplication de ladite 
commande elementaire ou sequence de commandes elementaires auxdits deuxiemes 
moyens de traitement de donnees. 

15. Terminal selon la revendication 14, caracterise en ce que lesdits premiers moyens 
30 logiciels (20, 71) de pilotage des moyens d'interface comportent au moins un quatri^me 

parametre secret, ledit deuxieme microprocesseur (3) etant commande. par ledit logiciel filtre 
(F, 62) pour authentifier lesdits premiers moyens logiciels (20, 71) de pilotage des moyens 
d'interface sur la base d'une information transmise par ledit premier microprocesseur (2) et 
combinee au moins avec ledit quatrieme parametre secret. 
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16. Terminal selon la revendi cation 15, caract<§ris<§ en ce qu'il comprend un deuxteme 
canal de communication (12) entre lesdits premiers moyens logiciels (20, 71) de pilotage des 
moyens d'interface et ledit deuxi£me microprocesseur (3) et des deuxtemes moyens de 
securisation dudit deuxteme canal de communication. 
5 17. Terminal selon la revendication 16, caracterise en ce que lesdits deuxtemes 

moyens de securisation comprennent des moyens de chiffrement et d<§chiffrement, par 
lesdits premiers moyens logiciels (20, 71) et par ledit deuxiSme microprocesseur (3), des 
donnees transmises sur ledit deuxteme canal de communication (12), sur la base d'au moins 
un cinquteme param6tre secret memorise dans lesdits premiers et deuxi^mes moyens de 
1 0 traitement de donnees. 

18. Terminal selon Tune quelconque des revendications 16 et 17, caracterise en ce 
que lesdits deuxiSmes moyens de securisation comprennent des premiers moyens physiques 
de protection dudit deuxteme canal de communication (12) contre les intrusions. 

19. TerminaUselon Pune quelconque des revendications 15 ^ 18, caracterise en ce 
15 que ledit premier microprocesseur (2) comporte une ntemoire temporaire (2b) pour le 

stockage dudit paramdtre secret et des deuxtemes moyens physiques de protection de ladite 
rrtemoire temporaire (2b) contre les intrusions. 

20. Terminal selon Tune quelconque des revendications 14 a 19, caracterise en ce 
que ledit deuxi^me microprocesseur (2) est un microcontr6leur. 

20 21 . Terminal selon la revendication 1 3, caracterise en ce que ledit logiciei filtre g&n&re 

des premieres commandes pour la mise en oeuvre de ladite sequence d'echanges de 
donnees entre ledit module terminal et ledit utilisateur et lesdits premiers moyens de 
traitement de donnees comprennent ledit dispositif d'ex<§cution du logiciei filtre et sont 
constituSs par un microprocesseur s£curis6 (29) adapte pour : 
25 * ex6cuter ledit logiciei filtre (F, 62) de traduction et de conversion desdites 

requites de haut niveau en au moins une sequence d'echanges de donnees entre le 
module terminal et I'utilisateur et/ou en au moins une commande 6l6mentaire ou une 
sequence de commandes £lementaires executables par lesdits deuxtemes moyens 
logiciels desdits deuxiSmes moyens de traitement de donnees (31), 
30 * piloter lesdits moyens d 1 interface (4-9) grSce auxdites premieres commandes 

gener^es par ledit logiciei filtre, pour la mise en oeuvre de ladite sequence d'echanges 
entre ledit module terminal (1 ) et ledit utilisateur. 
22. Terminal selon la revendication 21, caracterise en ce que ledit microprocesseur. 
(29) comporte ladite m^moire programmable. 
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23. Terminal selon fa revendication 21, caracterise" en ce que ladite m§moire 
programmable est exteme audit microprocesseur (29). 

24. Terminal selon la revendication 23, caracteVise" en ce que ledit logiciel filtre (F, 62) 
est stocke sous forme chiffree dans ladite mSmoire programmable et en ce que ledit 

5 microprocesseur (29) comprend des moyens pour lire, dechiffrer et executer ledit logiciel filtre. 

25. Terminal selon I'une quelconque des revendications 14 a 24, caracteris<§ en ce 
que lesdits deuxiemes moyens de traitement de donnees dudit dispositif personnel de 
securite (31) comprennent un deuxieme dispositif de traitement de donnees (30) pour 
Pexecution securisee d'un logiciel filtre et une memoire programmable (30a) pour le 

10 chargement et le stockage dudit logiciel filtre (62), lesdits premiers moyens logiciels desdits 
premiers moyens de traitement de donnees &ant adapted pour recevoir lesdites commandes^ 
pour la mise en oeuvre de ladite sequence d'echange de donnees indifferemment de I'un ou 
I'autre desdits dispositifs (3 ; 29 ; 31) d'execution de logiciel filtre implanted dans ledit 
module et ledit dispositif personnel de securite" respectivement. 

1 5 26. Terminal selon Tune quelconque des revendications 1 3 k 25, caracterise en ce que : 

- ledit logiciel filtre (F, 62) comprend au moins un param^tre secret, 

- lesdits deuxiemes moyens de traitement (30) de donnees comprennent des seconds 
moyens de contrOle d'accSs conditionnels pour n'autoriser I'execution desdits calculs 
cryptograph iques, en reponse k des commandes elementaires generees par ledit logiciel filtre 

20 (F, 62), que si au moins une seconde condition pr£d£finie, fonction dudit param&re secret est 
remplie. 

27. Terminal selon Tune quelconque des revendications 1 a 12, caracterise en ce que 
ledit dispositif personnel de securite (131) comporte ladite memoire programmable (130a) 
pour le chargement et le stockage dudit logiciel filtre (F, 62). 

25 28. Terminal selon la revendication 27, caracterise en ce que ledit logiciel filtre (F, 62) 

gen£re des premieres commandes pour la mise en oeuvre de ladite sequence d^changes de 
donnees entre ledit module terminal (1) et ledit utilisateur et ce que lesdits premiers moyens 
de traitement de donnees comprennent un premier microprocesseur (2 ; 102) de pilotage 
desdits moyens d'interface (4-9), programme grace auxdits premiers moyens logiciels (20, 

30 71), pour executer lesdites premieres commandes, g<§n£r6es par ledit logiciel filtre (F,62), et 
lesdits deuxiemes moyens de traitement de donnees comprennent un deuxieme 
microprocesseur s6curise (130) du type pour carte k circuit integre dispose dans ledit 
dispositif personnel de securite (131) et comportant ladite memoire programmable (130a), 
ledit second microprocesseur (130) executant (i) ledit logiciel filtre (F, 62) pour le pilotage de 

35 ladite sequence d'6changes de donnees au moyen desdites premieres commandes 
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transmises audit premier microprocesseur (2 ; 102), ainsi que (ii) lesdites commandes 
Slementaires. 

29. Terminal selon les revendications 6 et 28, caracterise en ce que lesdits premiers 
moyens logiciels (20, 71) de pilotage desdits moyens <f interface comportent au moins un 

5 param£tre secret et ledit second microprocesseur (130) dudit dispositif personnel de securite 
(131) est commands par ledit logiciel filtre (62) pour authentifier iedit premier 
microprocesseur (2) sur la base d'une information transmise par ledit premier 
microprocesseur (2) et combinee au moins avec ledit param6tre secret. 

30. Terminal selon Tune quelconque des revendications 28 et 29, caracterist en ce 
10 que ledit deuxieme microprocesseur (130) dudit dispositif personnel de securite (131) est 

adapts pour commander le chargement dudit logiciel filtre (F, 62) dans ladite memoire 
programmable (130a) via lesdits premiers moyens d'interface (7-9) et lesdits troistemes 
moyens (6) d'interface avec ledit dispositif personnel de securite (131). 

31. Terminal selon I'une quelconque des revendications 13 k 30, caracterisS en ce 
15 que ledit module terminal (1 ; 101) est constitue par un lecteur de carte £ circuit integre et 

ledit dispositif personnel de securite est une carte d circuit integre (31 ; 131). 

32. Terminal selon la revendication 13, caracterise en ce que ledit module terminal (1) 
comprend un ordinateur personnel (102) et en ce que ladite memoire reprogrammable est 
constitute par le disque dur (102b) dudit ordinateur. 

20 33. Terminal selon la revendication 32 et Tune quelconque des revendications 14 a 

17, caracterise en ce que ledit premier microprocesseur est constitue par le microprocesseur 
(102c) dudit ordinateur personnel (102), ledit ordinateur personnel (102) etant en outre 
interface audit microprocesseur s6curis£ (3). 

34. Terminal selon la revendication 32, caracterise en ce que ledit logiciel filtre (F) 
25 comprend un premier module de chargement/d^chiffrement (Fed) et un deuxieme module 

chiffte (Fchi) pour ladite traduction des requites de haut niveau, ledit premier module (Fed) 
commandant le chargement dudit deuxieme module (Fchi) en memoire RAM dudit ordinateur 
(102) et son dechiffrement pour I'exScution dudit logiciel filtre par ledit ordinateur. 

35. Terminal selon la revendication 32, caracterise en ce que ledit logiciel filtre (F) 
30 comprend au moins un premier module (F-PQ implante sur ledit ordinateur personnel (1 02) et au 

moins un deuxieme module (F-SE) implante sur un serveur de securite (Ssec), ledit ordinateur 
personnel (102) et ledit serveur de securite (Ssec) etant connectes par un canal de communication 
sScurise (CS) permettant un ^change de donntes protege entre lesdits modules. 

36. Terminal selon I'une quelconque des revendications 32 h 35, caracterise en ce 
35 que ledit dispositif personnel de securite (31) est une carte k circuit integre. 
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37. Systeme pour la mise en oeuvre de transactions s6curis6e, caracterise en ce qu'il 
comprend au moins un terminal (1, 31 ; 101, 131) selon Tune quelconque des 
revendications 1 k 36, et au moins une unite 6lectronique (Sap ; PC) comportant des moyens 
pour transmettre lesdites requfites de haut niveau audit terminal (1, 31 ; 101, 131). 
5 38. Systeme selon la revendication 37, caracterise en ce qu'il comprend une plurality 

de terminaux (1, 31 ; 101, 131), au moins un serveur (S) constituant ladite unite 
Slectronique, et des moyens (CR) de transmission de donn^es nurrteriques entre ledit serveur 
(S) et lesdits terminaux. 
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The present invention concerns a terminal and a system for performing secure 
electronic transactions. 

Public digital data transmission networks, such as the Internet, are expanding at a 
considerable rate. However, the performing of secure electronic transfers on this type of network 
5 is currently being hampered, among other things, by the lack of security mechanisms associated 
with such transactions, reflected in a lack of confidence on the part of network users and 
operators. 

In the context of this application: 

- an electronic transaction designates an exchange of information via a public digital 

1 o data transmission or telecommunication network, either between two or more users or between a 

user and a service provider, 

- a function is a process carried out in order to render a service to a user, 

- an application designates a consistent set of services and functions, 

- the expression "application software" designates the software needed to perform the 
1 5 functions relating to a given application, and 

- a secure transaction is a transaction for which security measures are implemented, 
namely authentication of the entities participating in the transaction, integrity, confidentiality, 
authenticity and possibly non-repudiation of exchanges and operations effected in the context of 
the transaction. 

20 Many applications require secure electronic transactions. Examples are controlling 

access to computer or similar resources, home banking (statements, transfers between 
accounts, etc ... via the telephone network or the Internet), electronic trading (purchase of goods 
or services via a public network), electronic mail, electronic purse, etc. 

These and other applications requiring secure transactions are well known to the 

2 5 skilled person and are not described in detail here. 

Depending on their nature, rendering such applications secure necessitates the use of 
one or more security services such as: 

- authentication, to guarantee the identity of an entity (a person or a system); 

- access control, protecting against unauthorised use or manipulation of resources; 

3 o - confidentiality, prohibiting disclosure of data to unauthorised entities; 

-data integrity, which assures that data has not been modified, deleted or substituted 
without authorisation, and 

-non-repudiation, which assures that a participant in an exchange of data cannot 
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subsequently deny the existence of the exchange. 

The combination of two existing techniques makes it feasible to employ the above 
security services, so offering a sufficient level of security for the performance of electronic 
transactions. 
5 These are: 

- public key and private key cryptography, because it guarantees non-repudiation and 
facilitates management of keys; and 

- the integrated circuit card (or smart card), because it is relatively inexpensive, easy to 
use and reliable because it uses dedicated microprocessors with hardware and software 

10 protection features so that read and write mode access to their memory can be barred. 
Integrated circuit cards offer the following services: 

* authentication of the cardholder or user: this operation authenticates the cardholder 
by means of a confidential code after which the card allows operations such as executing 
algorithms, reading secret keys, reading or writing data on the card, which can also be subject to 

15 other security conditions; 

* protection of data and functions stored on the integrated circuit card. Access to the 
card can be subject to prior authentication of the electronic entity requesting to access it. This 
external authentication is generally effected in challenge/response mode. In this case the entity 
has a secret parameter, hereinafter also called the secret, enabling it to calculate, depending on 

20 a challenge issued by the card, a response that will prove to the card that it is in possession of 
the secret; 

* execution of cryptographic algorithms using a secret parameter stored on the card 
(encipherment, message authentication, signature); and 

* internal authentication. This service enables an application to authenticate the card. 
25 This service is the inverse of external authentication. The card generates a response to a 

challenge received and a secret stored on the card. 

The services offered by means of the integrated circuit card are performed on receipt of 
so-called elementary commands, execution of the elementary command causing the sending of 
elementary responses. The elementary commands concern, for example, cryptographic 
3 0 calculations, reading or writing of secret or other data, intervention of the user (entry of their 
personal confidential code (PIN), validation of a transaction after signature), and return of 
information to the user (display of messages to be signed, for example). 

Some cards offer the facility to verify the integrity, source and even the confidentiality of 


commands sent to the card. These services are based on techniques of authenticating and 
enciphering the commands. 

The current use of integrated circuit (or microcircuit) cards offers a very high level of 
security because the transactions are essentially performed on private networks and terminals 
(automatic teller machines, point of sale terminals, for example) which are under the control of an 
entity assuring the security of the system as a whole. 

In such applications, users or abusers do not have access to the application software 
or to the hardware and software security mechanisms of the terminals. 

In contrast, performing secure transactions using integrated circuit cards on a public 
network presupposes that users have access to a card reader terminal module, given that 
microcircuit cards do not have their own electrical power supply and that using them requires a 
reader that can power them up and establish communication with the user and/or external 
electronic means. 

At present, to perform a transaction on a public network, the user employs a terminal 
that can be a dedicated product, a personal computer or a personal computer connected to an 
integrated circuit card by a card reader. 

In all cases, the transaction system accessible to the user generally comprises: 
•an application service provider, for example an Internet browser, an electronic mail program, a 
home banking program, 

•a high-level security service provider enabling execution of low-level cryptographic mechanisms 
required by the application. 

The application service provider issues requests for high-level security services to 
assure the security of the transactions performed. 

If the application is installed on the user's personal computer, the cryptographic 
services referred to are, for example, those defined by RSA laboratories in its standard "PKCS 
11 : Cryptographic Token Interface Standard" or the cryptographic services offered by the 
Microsoft Windows NT operating system, in particular those available via the "Crypto API" 
application program interface (API). 

If the user does not have an integral microcircuit card reader, the cryptographic 
services are effected entirely by software. 

If the user wishes to enhance security, they use a transparent type integrated circuit 
card reader connected to their computer. A transparent type card reader is in fact an interface 
module between the computer and the integrated circuit card for transmitting elementary 
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commands from the computer, originating from the cryptographic service provider, to the card, 
and elementary responses from the card to the computer. Using this terminal, consisting of their 
terminal module - computer + reader - coupled to their card, a user can perform electronic 
transactions (electronic shopping, for example). 
5 Of course, access of users to a terminal of this kind generates potential security risks. 

The more decentralised the applications the greater the risk. Conversely, the better the 
control of the risks at the terminal end, the more decentralised can the applications be. Consider 
purse type applications, for example, in which transactions (purchaser card debit/merchant card 
credit) are effected card-to-card, without requiring consolidation of the transactions at the level of 
10 a centralised server. 

It follows from the foregoing discussion that a terminal can potentially contain a set of 
information (or even software) on whose confidentiality and integrity the security of the 
application relies. Consider, for example, secret keys used to authenticate the terminal modules 
vis k vis the card or to encipher data transferred between a server and the card reader terminal 
15 module. An abuser with access to the terminal can analyse its operation and obtain access to 
the confidential information and software. 

Note also that the applications referred to here, such as electronic shopping and 
electronic mail, are usually performed via the Internet. Experts are well aware that a personal 
computer (PC) connected to the Internet is highly vulnerable to viruses which can be installed 

2 o and execute on the user's PC without them knowing it and without them allowing physical access 

to their computer to anyone at all. The totally invisible nature of this type of threat is the real 
danger currently limiting the deployment of transaction-based applications using the Internet. 
The same comments apply to electronic shopping applications on cable TV networks using set- 
top boxes connected to the TV set and incorporating one or two smart card readers. 
2 5 The system level risks are then: 

• Attack on the integrity of the cryptographic service provider and the application 
service provider with the aim of modifying the behaviour of the terminal module: for example, the 
terminal module is modified to capture information associated with the card and to store the 
information obtained for subsequent communication to a counterfeit server. This attack can be 

3 o carried out unknown to the legitimate user (substitution of the user's terminal module or loan of a 

modified terminal module). This attack can then be generalised by circulating counterfeit 
terminal modules. 

• Attack on the confidentiality of the cryptographic service provider, with the aim of 
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obtaining the cryptographic keys they use, which are stored on the hard disk of a computer, for 
example. 

• Attack on other cards, based on the ability to authenticate the abuse vis a vis other 
cards by virtue of the secrets discovered by attacking the confidentiality of the service provider. 
5 • Attack on the integrity and the confidentiality of communications between the various 

entities (application service providers, cryptographic service providers, integrated circuit card 
reader, integrated circuit card, server) to break the chain of confidence established between 
these elements. For example: 

1 - deciphering communications between server and terminals; 
io 2 - inserting third party software between the application service provider and 

the cryptographic service provider to break the chain of confidence between these two programs 
or to substitute for the application software third party software causing the security service 
provider to execute security requests with a different aim to that of the application known to the 
user. 

15 • Attack on servers (in the case of an on-line application): connection of a counterfeit 

terminal to a server, emulation of a terminal module/integrated circuit card combination to obtain 
advantages. 

An attack on the chain of confidence between the cryptographic service provider and 
the application service provider in the context of an application requiring an electronic transaction 
20 using an integrated circuit card to be signed is illustrated hereinafter. The transaction proceeds 
as follows: 

- Step 1: verification of the personal confidential code (PIN) of the user, entered by the 
latter via a keypad associated with their terminal module, the code entered being sent to the card 
for verification by the latter. 

2 5 - Step2 : authentication of the terminal module. The latter sends a "challenge request" 

command (a challenge is a random or pseudo-random number). The integrated circuit card 
generates the challenge and sends it to the terminal module. The terminal module sends the 
card an "external authentication" command accompanied by a response consisting of the 
challenge enciphered by a key held by the terminal module. The integrated circuit card then 

3 o verifies the response received. 

- Step 3: if steps 1 and 2 are executed satisfactorily, the integrated circuit card is ready 
to receive and to execute the signature command, i.e. command of encipherment, using a secret 
key stored on the card, of the result of a hashing operation performed on the transaction entered 
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by the user. After this encipherment the card sends to the terminal module the signature 
consisting of the result of the hashing operation enciphered in this way. 

If the integrity of the application software (application service provider and its 
cryptographic service provider) is not assured, a hacker does not need to know the secret code 
5 and keys to pirate the transaction system; all that is necessary is to implant in the terminal 
module, for example the personal computer to which an integrated circuit card reader is 
connected, virus type software which in step 3 diverts the authentic data to be signed and sends 
falsified data to the card. Given that steps 1 and 2 have been executed in a satisfactory manner, 
the card will then sign the falsified data on the basis of the PIN that the user has entered and the 

1 o user will believe that the card is about to sign their own data. 

The preceding example shows the necessity of protecting not only the confidential 
information used in the context of a transaction but also the integrity of the transaction, i.e. the 
integrity of the behaviour of each entity involved in the transaction, together with the integrity of 
the behaviour of all of the software, assuring that the chain of confidence established between 
15 the various entities is broken. 

* The risks of attack mentioned hereinabove are currently covered in part by terminals - 
integrated circuit card readers integrating security modules (SAM, similar to an integrated circuit 
card) used in the context of purse applications in particular. The reader is then personalised by 
a SAM and assigned to a merchant, the cards read being those of customers. The SAM 
20 contains secret information and is able to execute algorithms using the secret information. 
However, it does not contain means for controlling communication with , the user, with the 
integrated circuit card and/or with external electronic means, and for this reason the security of 
transactions is not assured. 

Document WO 95/04328 discloses a terminal module comprising user interface means 

2 5 and interface means to external electronic means (hereinafter called external interface means) 

including an interface with a microcircuit card. The microprocessor of the terminal module 
comprises data storage means (ROM, EEPROM, RAM). The data stored in permanent memory 
(ROM) includes an operating system, managers of external components controlling the 
interfaces and peripheral devices, and an interpreter capable of interpreting program modules 

3 o written in a specific language. The program modules are stored in the semi-permanent memory 

EEPROM and can be loaded into temporary memory RAM to be executed by the microprocessor 
on activation of an appropriate interface by the user. The program modules corresponding to the 
applications of the terminal module are downloaded into the EEPROM of the microprocessor or 
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into a microcircuit card from an external server. 

The terminal module of document WO 95/04328 can operate: 

- in autonomous terminal module mode, the microprocessor of the terminal module 
executing a program module stored in an internal memory without calling on an integrated circuit 

5 card; 

-in autonomous terminal mode, in which a program module stored on a card is 
executed; 

- in extended terminal mode or on-line mode, in which the microprocessor of the 
terminal module or that of the card executes a program module and communication is 

10 established via the telephone, a modem or a direct connection to a service provider or a server; 
and 

- in transparent memory card reader mode, in which instructions received over a serial 
link are sent directly to the card and vice versa. 

The terminal described in document WO 95/04328 does not deal with security 
15 problems addressed by the invention in that there is no description of how to secure a 
transaction to guarantee the integrity of the behaviour of all of the software executing the 
transaction. In particular there is no description of means for executing high-level requests 
issued by the application or how to guarantee the source, the integrity and the confidentiality of 
such means. 

2 0 The present invention aims to provide a terminal for carrying out secure electronic 

transactions of the type comprising a personal security device such as an integrated circuit card 
or other device fulfilling the same functions and a terminal module provided with means of 
interfacing the personal security device, such as an integrated circuit card reader, and offering by 
virtue of its software and/or hardware architecture and the security mechanisms that it includes 

2 5 an enhanced level of security compatible with the fact that the terminal can be under the control 

of users (as opposed to terminals under the control of the operators). 

A second objective of the invention is to assure this same level of security whilst 
enabling integration, during use, of new functions or applications, or modification of existing 
functions or applications without having recourse to a multitude of different terminal modules and 

3 o without changing terminal modules to effect such modifications. 

To this end, the invention consists in a terminal for execution of secure electronic 
transactions by a user in conjunction with at least one application installed on an electronic unit, 
said terminal comprising: 
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- a terminal module including at least: 

* first interface means with said application for receiving from it requests 
relating to said transactions, 

* second interface means with said user; 

* third interface means with a personal security device, 

* first data processing means comprising at least first software means for 
controlling said interface means, and 

- a personal security device including at least second secure data processing means 
comprising at least second software means for executing elementary commands and means for 
executing cryptographic computations, 

characterised in that: 

- said terminal is adapted to receive said requests from said application installed on 
said electronic unit in the form of high-level requests independent of said personal security 
device, 

- at least one of said terminal module and said personal security device comprises: 

* at least one programmable memory for storing at least one filter program for 
translating said high-level requests into at least one of either (i) at least one command or a 
sequence of elementary commands for being executed by said second software means of said 
second data processing means, or (ii) at least one sequence of data exchanges between said 
terminal module and said user via said second interface means, said data exchanges being 
executed by said first software means of said first data processing means, 

* means for protecting said filter software to prevent an unauthorised person 
reading and/or modifying said software, and 

- at least one of said first and said second data processing means comprise a data 
processing device for executing said filter program. 

The invention defined hereinabove achieves the security objectives required for 
carrying out electronic transactions by virtue of the fact that it describes a filter or "firewall" 
between the external world, i.e. the applications themselves, and the security means and 
peripheral devices that it controls, by means of a logical interface defining the format of high- 
level requests issued by the applications and of a translation software for processing these 
requests. 

The terminal of the invention preferably comprises one or more of the following 
features, possibly in combination: 
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-said device for executing the filter program comprises first means for identifying 
and/or authenticating said application installed on said unit or the source of said requests sent by 
said application, 

- said data processing device for executing said filter program comprises means for 
5 verifying the integrity of data received from said application, 

- said data processing device for executing said filter program comprises centralised 
means for controlling conditions of use of services of the personal security device in accordance 
with said application and/or the user, 

- said data processing device for executing said filter program comprises: 

10 * means for commanding secured loading of said filter program into said 

programmable memory via said first or said third interface means from an entity external to said 
module, and 

* first access control means for authorising said loading of said filter program 
only in response to at least one predefined condition, 
15 - the terminal comprises second means for authentication of said first data processing 

means by said second data processing means, 

- the terminal comprises third means for authentication of said second data processing 
means by said first data processing means, 

-the terminal comprises a first communication channel between said first data 
20 processing means and said second data processing means and first means for securing said 
first communication channel, 

- the terminal comprises fourth means for authentication of said terminal module by 
said user, independently of said card, 

- said fourth authentication means comprise means for calculation by said first data 

2 5 processing means and for presentation to said user via said second interface means of a 

password known to said user and computed on the basis of a first secret parameter stored in 
said first data processing means, 

- the terminal comprises fifth means for conjoint authentication of said terminal module 
and said card by said user, and 

3 0 -said fifth authentication means comprise means for computation by said device for 

executing said filter program and for presentation to said user via said second interface means of 
a password known to said use and computed on the basis of at least second and third secret 
parameters stored respectively in said first data processing means and said second data 


processing means. 

In a first embodiment of the invention the terminal module is a personal computer and 
said programmable memory is the hard disk of said computer, said filter software is executed on 
the personal computer, or in a second mode of execution said programmable memory is on a 
secure server connected to the personal computer, the part of the filter software to be protected 
being executed on said secure server. 

In a second embodiment of the invention the terminal module is a device such as a 
dedicated integrated circuit card reader, in which case said personal security device is an 
integrated circuit card or a personal computer. This embodiment differs from the preceding one 
in that said programmable memory is integrated into a secure microprocessor, said filter software 
being executed in said secure microprocessor. The dedicated terminal module can be portable. 

Depending on the mode of execution of this second embodiment of the invention, the 
programmable memory for loading and storing the filter software can be in the personal security 
device or in the terminal module. In the latter case: 

- the terminal module can include a single microprocessor for executing the filter 
software and for controlling the interfaces or two microprocessors respectively implementing 
these two functions ; 

- preferably, said filter program comprises at least one secret parameter, and said 
second data processing means comprise second means of conditional access control for. 
authorising execution of said cryptographic computations in response to elementary commands 
generated by said filter program only if at least a second predefined condition depending on said 
secret parameter is satisfied. 

According to other features of the invention, when the terminal module comprises two 
microprocessors for executing the filter software and for controlling the interfaces : 

- the terminal comprises a second communication channel between said first software 
means for controlling the interface means and said microprocessor and second means for 
securing said second communication channel ; 

- said second securing means comprise means for encryption and decryption, by said 
first software means for controlling the interface means and said second microprocessor, of data 
sent on said second communication channel on the basis of at least a fifth secret parameter 
stored in memory on said storage means ; 

- said second securing means comprise first physical means for protecting said second 
communication channel against intrusion. 


Various embodiments of the invention will now be described with reference to the 
accompanying drawings, in particular embodiments in which the filter software is loaded and 
executed in the terminal to guarantee its source, its confidentiality and its integrity, the software 
being also able to authenticate the source of requests sent to it if confidence in the interfaces 
with the user, i.e. the screen and the keyboard, cannot be guaranteed. 

- Figure 1 is a diagram showing the functional architecture of a system for carrying out 
secure transactions by means of a terminal in accordance with the invention; 

- Figure 2A shows a first embodiment of the invention in which the terminal is a 
personal computer connected to an integrated circuit card by a reader, the application being 
installed on the personal computer or on a remote server; 

- Figure 2B explains the functional architecture of one variant of the first embodiment of 
the invention in which the personal computer serving as a terminal is connected to a security 
server on which the filter software is installed; 

-Figure 3 shows a transaction system using a terminal constituting a second 
embodiment of the invention, which can be a dedicated product connected as a peripheral 
device to a personal computer or directly to a server or based on a personal computer; 

- Figure 4A is a block diagram of the hardware architecture of the electronic circuits of a 
first mode of execution of the terminal from figure 3; 

- Figure 4B is a functional diagram illustrating a first software architecture configuration 
of the terminal from figure 4A; 

- Figure 4C is a functional diagram similar to that of figure 4B showing a second 
software architecture configuration of the terminal from figure 4A; 

- Figure 5 is a block diagram of the hardware architecture of the electronic circuits of a 
second mode of execution of the autonomous terminal from figure 3; 

- Figure 6 is a block diagram of the hardware architecture of the electronic circuits of a 
third mode of execution of the autonomous terminal from figure 3; 

-Figure 7 is a diagram illustrating the conventional software architecture of a 
microcircuit card; 

- Figure 8A is a diagram illustrating the software architecture of a transaction system 
comprising the terminal from figure 4A; 

- Figure 8B is a diagram illustrating the software architecture of a transaction system 
comprising the terminal from figure 6; 

-Figure 9 is a diagram illustrating the implementation of an electronic trading 
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application by means of a system in accordance with the invention; and 

-Figure 10 is a flowchart showing the process of downloading a program into a 
reprogrammable memory of the terminal module from figure 4A or figure 5 or of a microcircuit 
card connected to the latter. 
5 Referring to figure 1, a system for carrying out secure transactions comprises a 

terminal module 1 for reading an integrated circuit card 31 or the like. The terminal module 1 
comprises a filter F consisting of a software module processing high-level requests issued by 
application service providers FAp external to the terminal module 1 by means of a logic interface 
F-API and user interfaces such as a display screen 4 and a keyboard 5 enabling a user to read 

1 o and enter data. It also comprises a reader or other communication interface 6 with a microcircuit 

card or any equivalent security device personal to the user of the token, "Java Ring" (from SUN), 
"iButton" (from Dallas Semiconductor Corporation), or soft token type and communication 
interfaces with at least one application service provider FAp which can be installed on a PC 
and/or on a server Sap, for example, data then being exchanged via a data communication or 
15 telecommunication network R, 

The terminal module 1 can be a dedicated terminal or integrated into a PC or into a 
network computer (NC) dedicated to network applications or into a cable TV network decoder 
(Set Top Box). 

The terminal module 1 can perhaps be used in autonomous mode, for example to read 

2 o information such as the contents of an electronic purse contained in a memory of the card 31 . 

To carry out secure transactions the terminal module 1 can be used on-line to a server 
Sap or off-line, the application FAp then running locally, for example on the PC: this is the case 
when, for example, a user must sign an electronic mail message or transactions that will be sent 
to an addressee. An operation of this kind does not imply connection to an application server at 

2 5 the time when the card 31 is used. 

In on-line mode, as represented in figure 3 in the case of a dedicated terminal module 
1 , the latter can be connected to the server Sap on which the application FAp is installed via the 
PC and a network R such as the Internet or through the intermediary of the telephone network R 
via a modem MO or a DTMF link with a telephone handset CT. Some transactions, such as 

3 0 reloading an electronic purse in the card 31, can necessitate bidirectional exchange of data with 

the server Sap and are therefore more ergonomic in on-line mode. 

Carrying out a transaction secured with a terminal module 1 and a card 31 implies that 
high-level software requests (for example: requests for signature, authentication, etc... which 
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must be processed so as to meet the required security objectives of the application program) will 
be sent from the application program installed on the server Sap for example (on-line mode) or in 
the PC or NC available to the user (off-line mode, for example signing of electronic mail) to the 
filter F controlling the security means. The filter F processes these requests by means of 
translation software to assure that the application or virus type software cannot have direct 
access to the cryptographic functions of the integrated circuit card 31. The processing of the 
high-level requests includes translation of these requests into an elementary command or a 
sequence of elementary commands which are executed by the personal security device. The 
high-level requests are formulated independently of the software and/or hardware design of the 
personal security device, i.e. they are not formulated as a direct function of the personal security 
device. 

The high level requests contain information specifically related to the process that will 
be executed by the filter F. In a simple example, a high level request can contain a single 
elementary command to be transferred to the personal security device, for example, an APDU 
(Application Protocol Data Unit) in the case of a smart card, attached to a Message 
Authentication Code that will enable the filter F to check the origin and integrity of this "request 
before sending the elementary command to the personal security device. In a more complex 
example such as a request to sign a document, the high level request will be transformed by the 
filter F into a sequence of elementary commands sent to the personal security device and 
eventually to the user interface. Thus, according to this definition and due to the fact that it 
contains specific information to be decoded by the filter F independently of the personal security 
device, the high level requests will be said to be independent of the personal security device. 

The filter F meets the security objectives required in that the translation software that it 
includes verifies the identity of the application issuing the service requests (or the source of 
requests directly) and is installed in a manner that guarantees the integrity and the confidentiality 
of the operations and data used to respond to service requests. 

A translation software is configured for one type of microcircuit card and translates a 
high-level request received from application software into an elementary command or a 
sequence of elementary commands that can be executed by the microcircuit cards and/or a 
sequence of exchanges of data with the user. 

The high-level requests are a list of commands used by the application programs to 
invoke the security services needed to identify and authenticate the person performing the 
transaction and to guarantee the source, the integrity and where applicable non-repudiation of 
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the transaction. A high-level request from an application (on a server or on the PC or NC) can 
be characterised by one or more of the following points : 

- it is independent of the basic means (cryptographic means, for example) used to 
respond to, its request and contains specific information to be processed by the filter F. 
Reciprocally, a plurality of applications can use the same security service provider, employing 
the same logic interface F-API defining these requests. 

- the processing of the request links the transaction in a certain manner to the user 
performing the transaction by means of at least one fixed or variable secret parameter stored in 
by the integrated circuit card of the user. 

- it can include information enabling the filter software F to verify its source and its 
integrity. Authentication can use a Message Authentication Code (MAC) or a code of the 
electronic signature type associated with the request. 

- if the transaction is not entered by the user on the terminal module itself, the request 
can contain the information needed for the user to verify the essential data of the transaction, if 
required and if the terminal module supports this option. 

The logic interface F-API for exchanging high-level security requests between the 
application and the translation software of the filter F can be standardised so that it is common to 
different application programs. Accordingly, the signature type request can be used by an 
electronic mail application and by purchasing software. It is therefore possible to change the 
application whilst retaining the security service provider or vice versa to replace the security 
service provider without changing the application. 

To guarantee the integrity of the chain of confidence between the application and the 
card, the translation filter software F identifies and even authenticates the source and the 
integrity of requests that it receives. Various methods are feasible for identifying the application 
issuing the requests: 

- an identification code can be integrated into the request itself and then verified by the 
filter software using information that it contains or that can be stored on the integrated circuit 
card; 

- the same objective can be achieved by comparing the result of a hashing operation 
executed by the filter software on the application software issuing the request with a result 
previously stored on the card, for example. This solution is particularly suitable for the situation 
in which the application is installed on the user's PC; 

-authentication can equally be performed by associating with the request a MAC 


calculated from the content of the request and a secret key shared between the application and 
the filter software. An equivalent principle can be used with a signature on the request 
calculated with the same information and a private key known to the application, the signature 
being verified with the corresponding public key known to the filter software. 

Figure 2A explains a first embodiment in which the terminal module 1 is a PC 102, the 
connection to the integrated circuit card 31 employing a reader 6 connected to or integrated into 
the PC 102. The PC 102 includes input/output interfaces 102a to the reader 6 and the server 
Sap. Depending on the nature of the reader connected to the PC, the user interface 
components can be the keyboard and the screen of the PC itself or a keyboard and/or an LCD 
display on the reader, for example. In this embodiment the filter F is installed and executes on 
the PC 102. The filter F, and therefore the translation software that it contains, can be stored on 
the hard disk (HD) 102b of the personal computer 102. To execute on the central processor unit 
or microprocessor 102c of the PC, the filter software is loaded into the random access memory 
(RAM) 102d of the personal computer 102. 

Because the hard disk of a PC is difficult to protect, the filter software F or at least the 
sensitive part of this software can be encrypted. For this purpose it can be divided into at least 
two modules: a loading/decrypting module Fed and a second module corresponding to the 
encrypted filter software itself. The first module enables the second module to be loaded into 
RAM, decrypted and then executed. Referring to figure 2A, the software module when 
decrypted and loaded into RAM is denoted Fdec. 

Programming languages like Java, with security mechanisms intrinsic to the language 
itself, strengthen the protection of the software. 

Another method of verifying the integrity of the filter software is to have the second 
module signed by an authority guaranteeing the content of the filter software by means of a 
private key that is kept secret by the authority. The first loading module then, at the same time 
as performing the decrypting operation, performs a hashing operation on the second module and 
verifies the signature of this module using the public key associated with the private key of the 
authority. 

The operations described above imply the use of keys on which the security of the 
application relies. These keys can be concealed in the loading module, stored in the reader 6, or 
stored on the integrated circuit card 31 itself. Another possibility is to install the decryption and 
integrity verification module in the reader 6. 

The object of the invention is to prevent a pirate from using the integrated circuit card of 


a user without their knowledge, for example by modifying the filter software controlling the card 
or the application software, or by loading a virus to bypass the application or the filter software. 
The embodiment described previously and its variants address these risks, by enabling 
verification of: 

- the integrity of the filter software, and 

- the source and the integrity of commands sent to the card via the reader 6, by 
authenticating them using a MAC, for example. The MAC can be verified by the reader 6 or the 
card 31 . Equivalent protection could be obtained by encrypting the dialogue between the filter 
software and the reader 6. A virus attempting to bypass the filter software would then send 
unauthenticated or incorrectly encrypted commands to the reader 6 or to the card 31; these 
commands would therefore be rejected by the reader or the card, preventing the virus from 
achieving its aims. To prevent a hacker from determining the keys used by a terminal by 
analysing the operation of another terminal, the keys used by various terminals must be 
diversified. 

The encryption and signature mechanisms that can be considered to address the need 
to protect the filter software are well known to the skilled person and are based on existing 
cryptographic techniques as described, for example, in "Applied Cryptography, Protocols, 
Algorithms, and Source Code in C n by Bruce Schneier, John Wiley and Sons, Inc., 1994 and for 
this reason will not be described in detail here. 

Installing the filter software on a PC cannot guarantee the same level of security as 
installing it in a dedicated terminal that can offer additional hardware security mechanisms as 
used in the other embodiments described later, these mechanisms offering physical protection of 
the filter software and the secrets that it contains. 

Figure 2B shows one variant of the figure 2A embodiment. This variant exploits the 
flexibility and the ease of connection of a personal computer to a network. This enables part of 
the filter software, and in particular the secrets, to be held by a secure server Ssec. 

In figure 2B the filter software is divided into two software modules, a module F-PC 
installed on the PC 102 and a module F-SE installed on a security server Ssec. The 
programmable memory previously referred to and storing the filter software is therefore in the 
secure sever Ssec in this variant, i.e. out of reach of unauthorised users. Likewise, the filter 
software or at least the sensitive part of the filter software F-SE requiring protection executes on 
the secure server Ssec. 

The software module F-PC installed on the PC 102 is connected by a secure channel 
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CS to the security server Ssec. The secure channel is an encrypted communication channel for 
exchanging protected data between the two filter software modules F-PC and F-SE and possibly 
reciprocal authentication of the two modules F-PC and F-SE. The secure channel can use well- 
known communication protocols such as SSL, for example. 
5 Setting up this secure channel CS therefore enables the first filter software module F- 

PC to send to the second filter software module F-SE requests received from the application FAp 
via the logic interface F-API together with information concerning identification of the application 
issuing these requests. After verifying the information relating to the application, and depending 
on the application and possibly on rights of the user, the second software module F-SE then 

10 translates these requests into a series of commands to the microchip card 31 and for controlling 
exchanges of data with the user. The commands generated by the module F-SE are then sent 
to the first module F-PC which routes them to the element concerned: the PC itself in the case of 
the commands controlling exchanges with the user or the integrated circuit card. For the 
commands controlling exchanges with the user to execute on the PC, the latter must include an 

15 interpreter software module I. The interpreter software enables display of messages on the 
screen 4 and input of information by the user via the keyboard 5. The interpreter software 
module is described in more detail in connection with figures 4B and 4C. 

This second mode of execution is based on the mechanisms described a propos the 
first mode of execution (figure 2A) insofar as the identification of the application (hashing or 

2 o signature, for example) and protection of commands sent to the card (addition of a MAC, for 
example) are concerned. On the other hand, it offers an enhanced degree of security insofar as 
the filter software module F-SE translating high-level requests received from the application FAp 
executes in a secure environment. In the context of the invention the server Ssec is deemed to 
be secure if it is not accessible physically or logically (i.e. via a network connection) to 

2 5 unauthorised persons. 

The second mode of execution shown in figure 2B is suitable for applications employed 
in a closed or private environment controlled by a central authority, as it necessitates a protected 
server administered centrally. This second mode of execution also offers the facility to define a 
centralised policy of access to cryptographic services offered by the integrated circuit card. This 

3 o access policy can be based on applications requiring the services of the card and on the users 

themselves. In the case of a business issuing its employees or customers integrated circuit 
cards enabling them to sign electronic mail and banking transactions, it can assure that only 
authorised users can sign: this mechanism can be implemented using the secure channel CS. 
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For each signature request issued by one of the applications deemed to be valid by the business 
(the electronic mail program and the bank transaction software), the software module F-SE will 
execute a request for authentication of the user. This request can be executed, for example, by 
sending a random number (challenge) to the card 31 via the secure channel CS. After the user 
enters their confidential code, the integrated circuit card calculates a dynamic password by 
encrypting the challenge using a secret key that it holds. The password is then sent via the 
secure channel CS to the software module F-SE. Knowing the user and therefore the secret key 
held on their card, the software module F-SE compares the password received with the 
password expected. This mechanism, known as challenge-response mode authentication, 
enables the software module F-SE to validate the user's identity. Thus the business that has 
issued the integrated circuit cards to the users can assure that only users who are still authorised 
can sign bank transactions, for example. 

By virtue of the secure and centralised means that it represents, the server Ssec 
enables not only secure installation of the filter software F-SE but also the facility of instituting a 
centralised policy for controlling use of security services offered by the integrated circuit card. 
The server Ssec enables a centralised policy to be instituted by virtue of the fact that the same 
server can be connected to a plurality of software modules F-PC installed on the personal 
computers of a plurality of users. Thus the server Ssec enables centralised definition and control 
of the conditions of use of security services offered by the cards issued to the various users in 
accordance with the profile of the application requesting the services and the rights of said users. 
Instituting this centralised policy implies the server holding the necessary information, i.e. the 
rights of users to use a particular security service in connection with a particular application. 

This second mode of execution (figure 2B), well suited to private environments, is 
difficult to apply to open applications where a secure central server Ssec is not feasible. 

Figure 3 shows a terminal module embodying functional architecture principles similar 
to those of figure 2B in a different embodiment requiring no centralised server. The terminal 
module in the second embodiment of figure 3 has a very high level of security, enabling it to 
assure local protection of the filter software F directly. 

In figure 3 one face of the terminal module 1 which can be a portable unit, caries the 
display screen 4 and the keyboard 5 and the unit contains the electronic circuits, which are 
preferably not accessible from the outside. The module 1 contains the reader 6 and has an 
opening for inserting the microcircuit card 31 into the reader 6. The mode of execution described 
with reference to figures 3, 4A, 4B and 4C must not be considered as limited to a dedicated 
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terminal. The following description applies to a PC-based or NC-based terminal. 

In a first mode of execution, shown in figure 4A, of this second embodiment of the 
terminal module of figure 3, the electronic circuits of the terminal module 1 are based on a 
standard microcontroller 2 and a secure microprocessor 3 which are interconnected and 
permanently installed in the module 1. As an alternative to this, the microprocessor 3 can plug 
into the module 1 by means of a connector 41 shown in dashed line in figure 4A. This 
description covers a generic mode of execution based on a standard microcontroller In a 
particular mode of execution that will be described later the microcontroller 2 can be a PC 102 of 
the type shown in figure 2B. 

The standard microcontroller 2 comprises a processor unit 2a, temporary memory 
(RAM) 2b and permanent memory (ROM) 2c. It is preferably a "monochip" microprocessor the 
software of which is mask-programmed in the permanent memory 2c and which integrates into 
the same integrated circuit standard interface management or control means, the processor unit 
2a, the temporary memory 2b and the permanent memory 2c. 

The interfaces or peripheral devices managed by the microcontroller 2 include the data 
display screen 4, for example a liquid crystal display, the keyboard 5 for entry of data by a user, 
the microcircuit card reader 6, an external connection interface 7, for example of the RS 232 or 
PCM-CIA type, an infrared link interface 8 and a DTMF device 9 for sending data over a 
telephone line. 

The components of the module 1 also include a clock 10 and an electrical power 
supply 1 1 for the various circuits and components of the module 1 . The electrical power supply 
11 can be a battery power supply if the module 1 is portable and autonomous. 

The task of the standard microcontroller 2 is to manage the environment, i.e. to control 
the interfaces 4-9 and the clock 10 together with the power supply 11 for selectively energising 
the secure microprocessor 3 in the case of an autonomous module 1. 

The standard microcontroller 2 therefore requires little computing power, little 
temporary memory (RAM) and no semi-permanent memory (EPROM OR EEPROM). The 
microcontroller 2 is write protected by virtue of the fact that programs (interface control and, as 
described below, interpretation, management of clocks and electrical power supply, etc) are 
mask-programmed in the permanent memory 2c. As will become apparent hereinafter, the 
standard microcontroller 2 can also contain one or more secret parameters on the basis of which 
it can be authenticated by the secure microprocessor of the terminal module and/or of an 
integrated circuit card. The secrets must therefore be protected against reading and writing. 
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They are preferably stored in the temporary memory (RAM) of a "monochip" microprocessor 
which cannot be written or read from the outside. The standard microcontroller 2 can also have 
additional security functions, for example to prevent fraud such as display of data different to that 
coming from the microprocessor 3. 
5 It is therefore of low cost and consumes little electrical power, which is particularly 

suitable for a portable product. The microcontroller can be an OKI MSM 63180, for example. 

There are preferably two clocks 10: a low-frequency clock 10a, for example a 
32.368 kHz clock, and a high-frequency clock 10b, for example a clock at 1 MHz to 12 MHz. 
The microcontroller 2 commands the connection of its system clock to one or other of these two 
10 clocks. 

The slow clock 10a times a timer 2d of the microcontroller 2 with a period of 0.5 s to . 
provide a real time clock in the module 1 , The processor unit 2a can also use the slow clock 10a 
for functions that do not require high calculation speed: in this case the system clock of the 
microcontroller 2 is connected to the slow clock 10a and the fast clock 10b is stopped. This 
15 mode of operation reduces the electrical power consumption of the module 1 which is 
advantageous if it is portable and battery powered. 

The microprocessor 3 which is read and write protected includes a central processor 
unit 3a, a temporary memory (RAM) 3b and a permanent memory (ROM) 3c, together with 
electrically reprogrammable semi-permanent memory (EEPROM or Flash RAM, for example) 3d 
2 o for storing the application programs of the module 1 . 

The secure microprocessor 3 is of the type used in microcircuit cards and has a limited 
number of inputs and outputs, its internal buses being inaccessible from the outside. It is 
manufactured with other security mechanisms specific to this type of microprocessor and well 
known to the skilled person, such as security matrix, memory scrambling, clock frequency 

2 5 control, reset control, etc mechanisms. 

Because the microprocessor 3 has a semi-permanent memory 3d it is possible to load 
one or more application programs into it from the outside, for example from a server or from a 
microcircuit card. It is therefore possible to modify the application(s) in accordance with 
requirements (access control, financial and/or commercial transactions, electronic purse, etc) for 

3 o which the module 1 is intended. If the size of the semi-permanent memory 3d allows it, it is also 

possible to install new applications during its use. 

Depending on the version chosen, the secure microprocessor 3 can compute 
cryptographic functions requiring large-scale computations embodied in RSA or DSA type 
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asymmetric algorithms or use simpler algorithms, for example DES type algorithms. 
The secure microprocessor 3 can be, for example: 

- a SIEMENS SLE44C160S non-cryptographic micro-processor, with 14 kbytes of ROM 
and 16 kbytes of EEPROM; 

5 -an SGS THOMSON ST16CF54A cryptographic micro-processor, with 16 kbytes of 

ROM, 4 kbytes of EEPROM and 480 bytes of RAM; 

- a PHILIPS P83C858 cryptographic microprocessor with 20 kbytes of ROM and 
8 kbytes of EEPROM. 

The secure microprocessor 3 is connected by the link 12 to the standard 
10 microcontroller 2 and by links 13 and 14 to the external interface 7 and to the microcircuit card 
reader 6 via respective switches-interface adapters 15 and 16. The switches-interface adapters 
15 and 16 are controlled by the standard microcontroller 2 via respective links 17 and 18. 

The standard microcontroller 2 comprises an interpreter program 20 (figs 4B and 4C) 
stored in the ROM 2c and enabling it to execute commands generated by the software for 
15 translating high-level requests forming part of the application or program(s), as described 
hereinafter. The interpreter 20 enables application programs stored in the secure 
microprocessor 3 to control the interfaces 4-9 via the link 12. The application programs can 
nevertheless be located and executed elsewhere than in the secure microprocessor 3, for 
example on a microcircuit card 31 inserted into the interface 6, for example a card supporting 
20 mechanisms for downloading and executing applications as described in French Standard 
NF EN 726-3, the title of which translates as "Integrated circuit cards and terminals for 
telecommunications. Part 3: Specifications of the card independent of the applications". 

Depending on the security rules to which they are subject, the application programs 
can also be divided between these various locations. 

2 5 Figure 4B is a functional diagram showing a first software architecture configuration of 

the module 1 from figure 4A in which all application programs A1, A2, An and security 
functions (condensate computations, symmetrical cryptographic algorithms such as DES or triple 
DES, asymmetric cryptographic algorithms as proposed by RSA) are implemented in the secure 
microprocessor 3. 

3 0 The applications denoted A1, A2, An hereinabove and in the remainder of the 

description comprise at least the filters F1, F2, Fn and thus in particular the software for 
translating requests from the application service provider(s) FAp forming part of the main 
application 54 (figure 8A). 
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The standard microcontroller 2 manages the environment using various interface 

drivers: 

- a driver 21 for the microcircuit card reader or interface 6; 

- a driver 22 for the serial link interface 7; 
5 ■ - a driver 23 for the keyboard 5; 

- a driver 24 for the infrared link interface 8; 

- a driver 25 for the display 4; 

- a driver 26 for the clock 1 0 and the power supply 11; 

- a driver 27 for the DTMF interface 9; and 

10 -a driver 28 for other interfaces, assuming that the module 1 includes one or more 

interfaces other than those represented in figure 2. 

The secure microprocessor 3 can therefore control the interfaces by means of 
commands which are interpreted by the interpreter 20 and executed by the standard 
microcontroller 2 using the drivers 21-28. 

15 Figure 4C shows a second software configuration of the module 1 from figure 4A in 

which one or more applications Ax and one or more cryptographic functions Sx are stored in a 
reprogrammable memory 30a of a secure microprocessor 30 of a microprocessor card 31. 
When the card 31 is inserted into the reader 6, the microprocessor 30 executes the applications 
Ax and the cryptographic functions Sx. Other applications and security functions can be resident 

20 in and executed by the secure microprocessor 3 of the module 1. For example, the 
microprocessor 30 of the card 31 can assure an electronic signature function assuming that the 
secure microprocessor 3 does not include a dedicated computation processor (cryptoprocessor). 
Reciprocally, if the secure microprocessor 3 includes a cryptoprocessor, it is possible for an 
application on the microcircuit card 31 to invoke cryptographic commands of the module 1 that 

2 5 will be executed by the secure microprocessor 3. 

In this second configuration, which otherwise is identical to that of figure 4B, the 
interpreter 20 has the same role relative to the microprocessor 30 as it has relative to the secure 
microprocessor 3. Thus the module 1 can execute different applications according to the type of 
microcircuit card 31 inserted into the reader 6, for example: 

3 0 - authentication of the user in the context of a banking transaction (balance enquiry, 

transfer of funds, etc) effected via a telephone line by means of the DTMF interface 9; 

- electronic purse balance enquiry or reloading from the module 1 when a microcircuit 
card 31 used as a purse is inserted into the reader 6. The module 1 offers the facility to manage 


23 


several different purses: bank purse, purse specific to an institution, for example; 

- reading a medical dossier on a medical card; 

- reading loyalty points on a card on which loyalty points are awarded to a consumer 
according to purchases made, participation in customer loyalty operation, etc. 

5 The mode of execution described hereinabove with reference to figure 4A and the 

software configurations shown in figures 4B and 4C likewise apply to a terminal based on a 
conventional PC additionally equipped with a secure microprocessor 3. In this mode of 
execution the microcontroller 2 corresponds to the PC 102 as shown in figure 2A, the processor 
unit 2a corresponds to the microprocessor 102c of the PC and the RAM 2b and the permanent 

10 memory 2c respectively correspond to the RAM 102d and the hard disk 102b. Likewise the 
inputs/outputs 102a of the PC correspond to the interface modules 7, 8 and 12 of figure 4A. The 
connection between the secure microprocessor 3 and the PC 102 can be a serial or parallel link 
or a connection to the PCMCIA type internal bus of the PC, or a direct connection to the PC 
motherboard. As an alternative to this, the secure microprocessor 3 can be fixedly or removably 

1 5 (via the connector 4 1 ) integrated with the PC keyboard . 

In this case the interpreter software module 20 and the peripheral driver software 
modules 21 through 28 are installed on and executed on the PC. The functional architecture of 
this mode of execution is equivalent to that shown in figure 2B, the interpreter module 20 
installed on the PC assuring the same role as the interpreter module I from figure 2B: it executes 

20 commands for controlling exchanges with the user received from the filter software F which is 
installed in a secure manner in the microprocessor 3 (Figure 4B) or the integrated circuit card 30 
(Figure 4C). 

The figure 5 diagram illustrates a second mode of execution of a second embodiment 
of the invention in which the electronic circuits of the terminal module 1 are based on a single 

2 5 microcontroller 29 replacing the microcontroller 2 and the microprocessor 3 and offering the 

same type of physical and logical protection as the microprocessors designed for integrated 
circuit cards. This microcontroller drives all the interface means 4-9 of the terminal module. It 
includes a processor unit 29a, a temporary memory (RAM) 29b, a permanent memory (ROM) 
29c and a semi-permanent memory (EEPROM) 29d for storing the translation software. The 

3 o processor unit 29a corresponds to both the data processing unit 2a controlling the interfaces and 

the processor unit 3a for executing the translation software. As previously, the terminal module 
1 can be based on a PC 102 to the internal bus of which is connected a secure microcontroller 
29 controlling the display screen 4 and the keyboard 5 of the PC directly. 
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In one variant the memory in which the software for translating high-level requests is 
stored, volatile RAM with backup power supply or semi-permanent memory (EEPROM or Flash 
RAM), can be external to the microcontroller 29. In this case the translation software can be 
encrypted and signed or protected by a message authentication code (MAC) to assure its 
5 integrity and it confidentiality. The software is read by the microcontroller 29, decrypted and then 
executed. 

In a third mode of execution represented in figure 6 of the second embodiment of the 
invention the terminal module 101 has no secure microprocessor 3. In figure 6 the same 
reference numbers as in figure4A denote the same elements. The microcontroller 2 controls the 

10 interface 6 and the switch-adapter 15 for connecting the secure microprocessor 130 of a 
programmable microcircuit card 131 in the interface 6 with the external link interface 7. In this 
case all of the applications A and the cryptographic functions C are stored in a semi-permanent 
memory (EEPROM or Flash RAM) 130a of the secure microprocessor 130 of the programmable 
microcircuit card 131 and implemented by the latter as described with reference to figure 4C in 

1 5 respect of the applications Ax and the cryptographic functions Cx. 

In the examples described previously, for simplicity, the microprocessor 30, 130 of the 
integrated circuit card and the secure microprocessor 3 possibly incorporated in the terminal 
module have a single communication port. This implies that in these examples exchanges 
between the various entities,, i.e. the electronic unit 154 (figure 8) containing the main 

2 o application, the secure microprocessor 3 and the microprocessor 30, 130 of the integrated circuit 

card, are effected via the microcontroller 2 or 29 of the terminal module. The above descriptions 
must not be considered as limiting on the invention: other implementations are feasible within the 
scope of the present invention. The secure microprocessors for integrated circuit cards currently 
available which can be used for the card itself (microprocessor 30, 130) or in the terminal module 
25 (microprocessor 3) can have two communication ports. Various embodiments optimising 
communication are therefore easy to envisage with this type of microprocessor. In figure 4C, for 
example, one port of the integrated circuit card 31 can be dedicated to controlling the user 
interface and therefore connected to the microcontroller 2, the other port being connected to the 
electronic unit including the main application, subject to appropriate interface adaptation. 

3 0 According to one important feature of the invention filter software is stored in the 

reprogrammable memory EEPROM associated with the secure microprocessor 3 or 29 of the 
terminal module 1 and/or the secure microprocessor 30, 130 of the card 31, 131. This filter 
software translates in a manner known in itself high-level requests from the server Sap or from 
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the PC into sequences of elementary commands that can be executed by these microprocessors 
(these commands are defined in part 4 of ISO standard 7816-4). In accordance with the 
invention, this filter software translates these high-level requests into sequences of exchanges of 
data between the terminal module 1, 101 and the user via the interface means such as the 
5 display 4 and the keyboard 5. 

This solution has the advantage of considerably reducing the flow of data exchanged 
between the terminal module 1, 101 and the server Sap or the PC, but requires secure 
installation of the translation software to prevent instructions sent to the microcircuit card from 
being modified. 

10 This filter software is an integral part of the portion of the application software installed 

in the terminal module 1 and/or the card 31 , 131 and can therefore be downloaded. 

Figure 7 illustrates the conventional software architecture of a microcircuit card (smart 

card). 

The various software layers are represented by a block 43 which comprises a 
15 "communication protocol" software layer 44 enabling commands to be received. These 
commands are decoded by an "APDU command interpreter" software layer 45 (APDU: 
Application Protocol Data Unit) the role of which is to route the commands to the processing 
modules, which can be: 

- secure file management services software 46; 
2 0. - cryptographic services software 47; 

- application software 48. 

The processing modules 46, 47, 48 rely on basic services offered by the operating 
system 49 of the microcircuit card. 

Figure 8A illustrates the software architecture of a system for carrying out secure 

2 5 transactions using terminal modules 1 provided with a secure microprocessor 3 in accordance 

with the mode of execution of the invention shown in figure 4A. 

Block 51 represents the software executed by the secure microprocessor 3 of the 
terminal module 1, block 52 the software executed by the microcontroller 2 or the PC 102 of the 
terminal module 1 , block 53 the software executed by the microprocessor 30 of a microcircuit 

3 o card 31 and block 54 the main application software (application service provider) installed on the 

server Sap or on a PC. 

Block 51 is similar to block 43 of figure 7, i.e. the secure microprocessor 3 has an 
architecture similar to that of an integrated circuit card. Block 51 comprises: 


- communication protocol software 60; 
-operating system 61; 

- a block 62 representing the portion of the application software installed in the terminal 
module 1, this portion of the application software essentially comprising the filter software 
previously mentioned. Various software modules of this type corresponding to various 
applications can co-exist in the secure microprocessor 3; 

- optionally, software 63 for authentication of the standard microcontroller 2 (by the 
secure microprocessor 3) and authentication of the secure microprocessor 3 of the terminal 
module 1 (by the microprocessor 30 of the card 31); 

- secure file management software 64; 

- cryptographic services software 65. 
Block 52 comprises: 

- communication protocol software 70; 

- a command interpreter 71 corresponding to the software 20 from figures 4B and 4C; 

- authentication software 72 for authentication of the standard microcontroller 2 (by the 
secure microprocessor 3 of the terminal module 1) in conjunction with the software 63; 

- software 73 for controlling resources internal to the microcontroller 2; 

- software 74 for controlling interfaces with the user drivers 23 and 25 for the screen 4 
and the keyboard 5); 

-software 75 for controlling the communication interfaces 7, 8 and 9 (drivers 22, 24, 

27). 

Finally, block 53 is similar to block 43 but in the example described with reference to 
figure 8A does not include any application or filter software. It comprises: 

- communication protocol software 80; 

- APDU command interpretation software 81 ; 

- secure file management services (for example PIN checking) software 82; 

- cryptographic services software 83 (symmetrical cryptographic computations using 
secret keys or asymmetric cryptographic computations using public and private keys, etc) for 
authentication of the secure microprocessor 3 of the terminal 1 (by the microprocessor 30 of the 
card 31) in conjunction with the software 63, among other functions; 

- the operating system 84 of the microprocessor 30 on the card 31 . 

The communication protocol 60, 70, 80 controls exchange of data between: 

- the microprocessor 30 of the card 31 and the standard microcontroller 2 of the 
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PC 1 02 of the terminal module 1 ; 

- the secure microprocessor 3 and the microcontroller 2 of the terminal module 1 ; 

- the secure microprocessor 3 of the terminal module 1 and the microprocessor 30 of 
the card 31. 

5 Figure 8B is a view similar to figure 8A illustrating the software architecture of the 

system in the situation where the terminal module 101 does not include the secure 
microprocessor 3, in accordance with the third mode of execution of the second embodiment of 
the invention (figure 6). 

In figure 8B ( block 152 represents the software executed by the microcontroller 2 of the 

10 terminal module 101, block 153 the software executed by the microprocessor 130 of a 
programmable microcircuit card 131, and block 154 the main application software installed on 
the server Sap or on a PC. 

Block 152 comprises the same software 70, 71 and 73 through 75 as block 52 from 
figure 8A and a block 76 which comprises software for authentication of the standard 

15 microcontroller 2 of the terminal module 101 (by the microprocessor 130 on the card 131). 

Block 153 relating to the microprocessor 130 of the card 131 comprises software 62 
and 80 through 84 of blocks 51 and 53 from figure 8A together with software 77 for 
authentication of the standard microcontroller 2 of the terminal module 101 (by the 
microprocessor 130 of the card 131) in conjunction with the software 76. 

2 o Unlike a conventional system, in a secured transaction system of the invention the filter 

software 62 which translates high-level requests from the application into elementary commands 
that can be executed by a microcircuit card is installed in the secure user environment, i.e. either 
in the terminal module 1 (for the applications A1, A2, An of the modes of execution from 
figures 4A-4C and 5) or on a semi-permanent memory card 31, 131 which can be used with the 

2 5 terminal module 1, 101 (for the applications Ax of the figure 4C embodiment and for all the 

applications of the figure 6 embodiment). 

Apart from its microcircuit card management function, the filter software 62 controls 
interaction with the user, i.e. the sequences of exchanges of data between a user and the 
terminal module which are required in the context of an application and which use the interface 

3 o means, namely the screen 4 and the keyboard 5. Note that the invention is not limited to the use 

of a screen and a keyboard as interfaces with the user and that any other type of interface with 
the required ergonomic features could be suitable, for example a voice interface. 

Transactions are secure because the filter software 62 is securely installed in the 
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secure microprocessor 3 or 29 of the terminal module 1 or the microprocessor 30, 130 of the 
microcircuit card 31, 131. The keys and rules necessary to access files on the microcircuit card 
31, 131 are contained in the translation software 62 and are therefore inaccessible to third 
parties. 

The functions of the filter software 62 will be illustrated hereinafter in the context of an 
example of an electronic trading application. The application includes the following entities: 

• a purchaser, 

• a merchant, 

• a bank. 

The merchant has an electronic trading server Sap (Web server) accessible via the 
Internet. The purchaser has: 

•a PC for accessing the electronic server Sap to consult a catalogue of products, 

•an integrated circuit card 31 supplied by the bank and the microprocessor 30 in which contains 

a private key but does not have any cryptographic capabilities connected with a signature, 
•a terminal module 1 as shown in the figure 4A embodiment, having a standard microcontroller 

2, a secure microprocessor 3 with cryptographic capabilities enabling a message to be 

signed, a keyboard 5, a display 4, an integrated circuit card interface 6 and a serial interface 

7 for connecting it to a PC. 

The principle of operation is as follows: the transaction is signed by the terminal 
module 1 using a private key held by the card 31 . This private key is protected by a confidential 
code (PIN) that the purchaser must enter in a secure environment, i.e. on the terminal 1 , and by 
prior authentication of the terminal 1 by the card 31 using a secret key Kauth. The private key is 
also transmitted in an encrypted manner (by means of a key Kchif) to set-up a secure 
communication channel between the microprocessor 30 of the integrated circuit card 31 and the 
secure microprocessor 3 of the terminal 1 . 

Figure 9 illustrates the exchanges between the various entities: 

a. the purchaser enters an order on the PC, 

b. the PC generates the transaction to be signed by the purchaser (product code, price) and 
requests the terminal module 1 to sign the transaction, 

c. the terminal module verifies the source of the request for signature and then prompts the user 
to enter their PIN code by displaying a message "enter PIN" on the display 4, 

d. the purchaser enters the code (PIN) on the keyboard 5 of the terminal module 1 , 


e. the terminal module 1 sends the PIN to the card 31 for verification; positive verification lifts 
one of two conditions of access to reading the private key, 

f. the terminal module 1 displays the transaction on its display 4, 

g. the purchaser confirms it by pressing a "confirm 11 key on the keyboard 5 of the terminal module 
1, 

h. the terminal module 1 submits an external authentication request to the card 31. External 
authentication enables the secure microprocessor 3 of the terminal module 1 to authenticate 
itself to the microprocessor 30 of the card 31 and thereby lift the second level of protection of 
access to the private key. This authentication is performed in challenge/response mode using a 
secret Kauth shared by the terminal module 1 and the card 31, 

i. the terminal module 1 sends a private key read request to the card 31 , 

j. all access conditions having been satisfied, the card 31 accepts the read request and sends 
the private key, which is encrypted using a secret key Kchif shared by the card 31 and the 
terminal module 1, 

k. the terminal module 1 decrypts the private key, signs the transaction by means of the private 
key, destroys the private key, disconnects from the card 31 and sends the signed transaction to 
the PC which sends it to the server S. 

The above example can easily be transposed to an electronic transaction performed 
without any PC, the.terminal module 1 being connected directly to a server Sap by a modem link 
(figure 3), the purchaser entering the order (product code) on the terminal module 1. 

Note that authentication of the secure microprocessor 3 by the card can also be 
effected by way of the read private key command by associating with it a message 
authentication code (MAC) calculated using a secret key. 

This example shows that the filter software 62 can translate a high-level "request for 
transaction signature" into a multitude of individual requests addressed to the various interfaces 
of the terminal interface 1, namely its interface 6 with the integrated circuit card 31, its interface 
with the display 4, its interface with the keyboard 5 and its interface for connecting it to the PC or 
the server Sap. 

Translation filter software of this kind has a screening role, providing a filter between 
the outside world, i.e. the applications, and the peripheral devices that it controls. 
It enhances security because: 

1. It imposes a sequencing of the individual instructions sent. For example, in the 
situation illustrated hereinabove, it requires the transaction to be confirmed by the user before it 
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is signed. 

2. It alone has the secret parameters for generating and authenticating these individual 
instructions. Thus it alone has the authentication and encryption keys for reading and decrypting 
the private key. 

When the filter software executes in the secure microprocessor 3 of the terminal 
module 1 these properties enable a policy of access to the card 31 to be imposed which is not 
always completely imposed by the card itself, or the capacities of a card to be expanded 
(signature capacity delegated to the terminal module, use in a context not foreseen when initially 
deployed). 

The advantages in terms of security of executing the filter software in the secure 
microprocessor of the terminal module or the integrated circuit card are possible only because 
the software executes in a secure environment, assuring that: 

• the secrets contained in the filter software are not accessible because they are stored in the 
secure microprocessor 3, 29, 30 or 130, 

• the confidentiality and the integrity of the filter software are preserved because the software 
is stored in the secure microprocessor 3, 29, 30 or 130. 

If the terminal module 1 is a dedicated product having its own interfaces (display 4 and 
keyboard 5) the security objective is achieved because the software controlling exchanges of 
data with the user cannot be modified because it is permanently stored in the permanent 
memory 2c of the microcontroller 2 or securely stored in the microcontroller 29. Thus the user 
can confidently confirm the content of their transaction by means of the display 4 and the 
keyboard 5 and the need to verify the identity of the application or the source and the integrity of 
requests becomes optional. 

Other mechanisms can further enhance the level of security of the chain of confidence 
between the secure microprocessor of the integrated circuit card, the secure microprocessor of 
the terminal module, when present, the standard microcontroller or the PC of the terminal 
module and the user. These mechanisms are: 

A) secure downloading of the filter software; 

B) authentication pf the standard microcontroller by the secure microprocessor or 
(which amounts to the same thing but is more suitable in the case of a mode of execution of the 
terminal based on a PC) authentication of the interpreter software module I (20) by the filter 
software F (62) and/or setting up of a secure communication channel between these two 
microprocessors or the programs I and F; 
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C) protection of a secret by the standard microcontroller; 

D) mutual authentication and setting up of a secure communication channel between 
the secure microprocessor of the integrated circuit card and the secure microprocessor of the 
terminal module; 

5 E) authentication of the terminal module and where applicable of the terminal 

module/card combination; and 

F) authentication of the microcircuit card by the terminal module. 
A) Secure downloading of the filter software 

The figure 10 flowchart illustrates the process of downloading an application program 
10 (filter software) into the secure microprocessor 3 or 29 of the module 1 or the secure 
microprocessor 30, 130 of a card 31, 131 in the reader 6. This downloading can be effected 
from a server Sap via the PC and the external connection interface 7 or the infrared link interface 
8, for example, or directly by means of a telephone connection via the DTMF interface 9. The 
downloading can equally be effected into the secure microprocessor 3 or 29 (if the terminal 
1 5 module has one) from a microcircuit card inserted into the reader 6. 

In step 32 the area of the memory 3d allocated to the application program to be 
received is empty and the microprocessor 3 is waiting to load the application program following a 
loading request. 

The next step 33 corresponds to a procedure for authentication by the microprocessor 
20 3 of the entity that will download the application program (sender). This authentication 
procedure can use encryption mechanisms well known to the skilled person, for example, such 
as symmetrical mechanisms using shared secret keys or asymmetrical mechanisms using 
private and public keys. 

Step 34 is a test to determine if the authentication procedure has succeeded. If it has 
25 not, the message "access refused" is displayed on the screen 4 (step 42) and the program 
returns to step 32; if authentication has succeeded, the process for loading the application 
program begins in step 35. 

Step 36 corresponds to storage in the EEPROM 3d of the data frames sent by the 
entity responsible for downloading. 
3 0 Step 37 is a test to determine if downloading has finished: if not, the downloading 

program returns to step 36 and downloading continues; if it has finished, the microprocessor 3 
verifies the integrity of the received data in step 38. To this end a message authentication code 
(MAC) can be associated with the downloaded program for verifying not only its integrity but also 
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its source. The MAC can be generated using a symmetrical cryptography mechanism (DES in 
chained CBC mode). The source and integrity can also be verified using an asymmetrical 
cryptography mechanism: a condensate of the downloaded software is signed by the sender 
using their private key; the secure microprocessor 3 then verifies the signature using the 
5 sender's public key. 

Note that in this last example the public key in theory does not need to remain 
confidential. The security features of the microprocessor nevertheless assure the integrity of the 
software, preventing a hacker from modifying the software to eliminate the signature verification 
or simply to substitute for the public key initially provided a public key for which they know the 

1 o associated private key. 

If the test 39 indicates that the data received is correct, a flag indicating that the 
application program received is valid is generated in step 40. Otherwise the downloading 
program returns to the first step 32. 

This process of loading the application software, and thus the filter software, into the 
15 secure reprogrammable memory (3d, 30a, 130a depending on the embodiment concerned) 
includes mechanisms for confirming the source and the integrity of the data received from the 
sender of the software. This prevents downloading by a hacker of filter software that could carry 
out transactions in the terminal module 1, 101 unknown to the user. 

B) Authentication of the interpreter software module I, 20, 71 by 
20 the filter software F, 62 or, which amounts to the same thing in the 
corresponding mode of execution, authentication of the standard 
microcontroller 2 by the secure microprocessor and/or setting up of a 
secure communication channel between the programs or between the 
microprocessors 

2 5 For a user to be totally confident in the terminal module they are using to carry out 

transactions it is necessary: 

-to authenticate the data sent from the interpreter software 20, 71 to the secure 
microprocessor 3, 30 or 130 executing the filter software; and 

-to assure that the data sent by the filter software to be displayed through the 

3 0 intermediary of the user's interpreter software of the terminal module 1, 101 can only be 

displayed by the latter. 

When the means of controlling exchange of data with the user, i.e. the interpreter 
software 20, 71, is installed in the terminal module 1, 101 in a fixed manner and cannot be 


modified, for example in the ROM 2c of the standard microcontroller 2, authenticating the 
software module is equivalent to authenticating the microcontroller. 

Likewise, when the filter software is installed in secure processing means such as the 
secure microprocessor 3, the integrated circuit card or the secure server Ssec, in a manner such 
that it cannot be modified by an unauthorised person, authentication by these secure means is 
equivalent to authentication by the filter software itself. 

In the following description the mechanisms for authentication of the software means 
controlling the interfaces or the interpreter software 20, 71 by the filter software will be described. 

Various solutions verify these conditions. 

A first solution consists in encrypting all the data exchanged between the interpreter 
software 20, 71 and the filter software. 

A second solution is to have the interpreter software 20, 71 authenticated by the filter 
software and/or to set-up a secure communication channel between them. 

These two solutions necessarily imply that at least one secret parameter known to the 
filter software F 62 is stored in the interpreter software 20, 71". 

In the second solution the filter software F 62 authenticates the interpreter software 20, 
71 using a conventional authentication process based on information sent by the interpreter 
software 20, 71 and combined with the secret parameter. At the level of the interpreter software 
20, 71 this authentication procedure is executed by the software 72 (figure 8A) or the software 
76 (figure 8B), depending on the embodiment of the terminal module concerned. 

This authentication mechanism can equally be applied to messages exchanged 
between the programs to construct message authentication codes for guaranteeing the source 
and the integrity of each message transmitted. 

In the case of the mode of execution described with reference to figure 4A, this solution 
nevertheless requires, for preference, physical protection of the link between the two 
microprocessors to be assured to prevent a hacker from reading the data exchanged and in 
particular the personal identification code (PIN) of the card, which the user may need to enter via 
the keyboard 5 to carry out transactions. 

C) Protection of a secret parameter by the standard 
microcontroller 2 

The foregoing description shows the necessity of storing at least one secret parameter 
in the interpreter software. The mode of execution of the terminal based on a PC, in which the 
interpreter software executes on the PC itself, therefore offers a limited degree of security for the 


PC, although this degree of security is sufficient to prevent a virus substituting itself for the 
interpreter software. A higher degree of security is obtained by installing the interpreter software 
in the ROM 2c of the standard microcontroller 2. For enhanced security the secret parameter of 
the microcontroller 2 can be stored in the temporary memory when the product is manufactured 
or possibly on inserting the microprocessor 3 if it is removable, or on an integrated circuit card. 
The aim of this operation is to establish confidence between the two microprocessors. All 
necessary precautions must be taken at the time of this operation to assure the authenticity of 
the microcontroller 2 (operation effected by the manufacturer, operation protected by transport 
keys stored in the temporary memory of the microcontroller 2 by the manufacturer, and 
knowledge of which is a precondition for initialising said secret parameter). In addition, 
conventional mechanisms for detecting intrusion (contacts, etc) will be fitted to erase the 
temporary memory in the event of intrusion (by cutting off the power supply, etc). 

D) Mutual authentication and setting up of a secure 
communication channel between the microprocessor of the integrated 
circuit card and the secure microprocessor of the terminal module 

* This mutual authentication and the setting up of the secure communication channel are 
effected by mechanisms identical to those used by the standard microcontroller 2 and the secure 
microprocessor executing the filter software, as described under B) above. 

E) Authentication of the terminal module 

It is important to guard against any attack on the combination of the keyboard 5, 
display 4 and secure microprocessor 3 with the aim of counterfeiting the terminal module, for 
example, substituting a counterfeit terminal module for a real terminal module in order to recover 
information entered by the user (keyboard spy), access the secrets of an integrated circuit card, 
falsify signatures. 

To this end a mechanism can be added to enable the user to authenticate the terminal. 

This objective is achieved by an automatic personalisation process. 
Authentication of the terminal module alone 

Personalisation can consist in calculating a password that is easy to remember and 
that is generated and displayed by the terminal in accordance with secret parameters contained 
in the microprocessor or microprocessors of the terminal when the user enters a PIN. If the 
terminal includes two microprocessors, for example, the password is stored in the secure 
microprocessor, encrypted using the PIN and a secret key X, and then sent to the microcontroller 
2 where it is decrypted using the key X also stored in the microcontroller 2 and the PIN entered 
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by the user. This mechanism aims to protect against substitution of one of the two 
microprocessors. 

The same principle can be applied to a card/terminal combination each time a 
microcircuit card is used with the terminal module. Personalisation can consist in the translation 
5 software calculating a password based on secret information held by the secure microprocessor 
of the card and secret information held by the terminal module, for example. The same principle 
as described hereinabove can be used to calculate the password. This password, generated the 
first time the terminal module is used in conjunction with the card and known to the user, is 
displayed on the screen 4 when the terminal module is used again with the card. The user can 
10 therefore verify and be assured that the terminal in their possession, consisting of the terminal 
module connected to the card, is authentic. 

F) Authentication of the microcircuit card by the terminal module 
To enhance further the security of the transaction system in accordance with the 
invention, a conventional authentication process can be used for authentication by the terminal 
15 module 1, 101 of the microcircuit card used. An authentication process of the above kind 
prevents the user's personal identification number (PIN), entered by the latter into the module 1, 
101 via the keyboard 5 to execute a secured transaction, from being captured by a counterfeit 
card substituted by a hacker for the user's authentic card and subsequently recovered by the 
hacker to read the PIN off the counterfeit card. This authentication can be effected by a means 
2 0 of a conventional challenge/response type mechanism, for example, using a secret shared 
between the card and the terminal module and symmetrical cryptography or, as already 
described, using a private key stored by the card enabling the challenge to be encrypted using 
an asymmetrical algorithm, the terminal module verifying the response using its public key. 

The architecture of the transaction system and the security mechanisms described 

2 5 hereinabove make transactions effected by means of the terminal module 1,101 highly secure. 

The terminal module: 

- expands the nature of the truly secure services that a microcircuit card can provide, 
thanks to the keyboard 5, the screen 4 and the protection of data exchanged with the user; and 

- enables the card to be used in a non-secure environment (PC susceptible to viruses 

3 0 or pirate programs), by hermetically isolating it from this environment by means of a software 

and/or hardware architecture strictly controlling access to the card, i.e. controlling commands 
sent to the cryptographic functions on the card. 

The terminal module can take various forms, for example: 


36 


•an integrated circuit card reader for connection to a computer via various interfaces (PCMCIA, 
etc) or not (connection to a server via modem only); 

•a computer (PC) the user interfaces of which consist in the screen and the keyboard of the PC 
and which includes an integrated circuit card reader. The PC will include software and/or 
hardware means (such as a secure second microprocessor, the standard microprocessor 
consisting of the PC itself) for assuring the integrity and the confidentiality of the filter 
software. By computer is meant a PC or a PDA (Personal Digital Assistant); 

•a keyboard, possible provided with an LCD display screen, incorporating a secure 
microprocessor and an integrated circuit card interface; 

•a telephone, possible equipped with a display, incorporating a secure microprocessor and an 
integrated circuit card interface; 

•a cable TV network decoder (set-top box) incorporating an integrated circuit card reader 
connected to a TV, the telephone, a keyboard or possibly the remote controller for the 
decoder or the TV providing the user interface; 

•more generally, any equipment that can be rendered secure by incorporating a secure 
microprocessor in which a sensitive application can be installed or by incorporating an 
integrated circuit card interface enabling said equipment to be controlled by an application 
installed on an integrated circuit card. 

The whole of the foregoing description describes a terminal to be used with an 

integrated circuit card or smart card. The card referred to is in fact a tool enabling the use of 

cryptographic functions personalised to one user by means of at least one secret parameter. 

The object of the invention is clearly not limited to a given form of tool such as an integrated 

circuit card. The invention also covers the use of personal security devices offering functions 

equivalent to those of an integrated circuit card but presented in a different form, such as the 

"(Button* 1 , "Java Ring" and "token" products. 
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CLAIMS 

1 . A terminal for execution of secure electronic transactions by a user in conjunction 
with at least one application installed on an electronic unit, said terminal comprising: 

- a terminal module including at least: 

5 * first interface means with said application for receiving from it requests 

relating to said transactions, 

* second interface means with said user; 

* third interface means with a personal security device, 

* first data processing means comprising at least first software means for 
10 controlling said interface means, and 

- a personal security device including at least second secure data processing means 
comprising at least second software means for executing elementary commands and means for 
executing cryptographic computations. 

characterised in that: 
15 - said terminal (1, 31; 101, 131) is adapted to receive said requests from said 

application (Fap) installed on said electronic unit (Sap; PC) in the form of high-level requests 
independent of said personal security device, 

- at least one of said terminal module (1; 101) and said personal security device 
comprises : 

2 0 * at least one reprogrammable memory (3d; 30a; 102b; 130a; Ssec)for storing 

at least one filter program (F, 62) translating said high-level requests into at least one of 
either : 

(i) at least an elementary command or a sequence of elementary commands that can 
be executed by said second software means (80-84) of said second data processing means (30; 

25 130), or 

(ii) at least one sequence of data exchanges between said terminal module (1 ; 101) 
and said user via said second interface means (4, 5), which can be executed by said first 
software means (1, 20, 71) of said first data processing means (2; 29; 102), and 

* means for protecting said filter program (F, 62) to prevent an unauthorised 

3 o entity from either reading and/or modifying said filter program, and 

- at least one of said first and said second data processing means (3; 29, 30; 102; 130; 
Ssec) comprise a data processing device for executing said filter program (F, 62). 

2. A terminal according to claim 1 characterised in that said device for executing the 


38 


filter program comprises first means for identifying and/or authenticating said application (Fap) 
installed on said electronic unit (Sap; PC) or the source of said requests sent by said application. 

3. A terminal according to claim 2 characterised in that said data processing device for 
executing said filter program (F f 62) comprises means for verifying the integrity of data received 
from said application (Fap). 

4. A terminal according to any one of claims 1 to 3 characterised in that said data 
processing device for executing said filter program (F, 62) comprises centralised means (Ssec) 
for controlling conditions of use of services of the personal security device (31) in accordance 
with said application (Fap) and/or the user. 

5. A terminal according to any one of claims 1 to 4 characterised in that said data 
processing device for executing said filter program (F, 62) comprises: 

- means for commanding loading in a secured manner of said filter program into said 
programmable memory via said first or said third interface means from an entity external to said 
module, and 

- first access control means for authorising said loading of said filter program only in 
response to at least one predefined condition. 

6. A terminal according to any one of claim 1 to 5 characterised in that it comprises 
second means for authenticating said first data processing means (2; 3; 29; Ssec) by said 
second data processing means. (30; 130). 

7. A terminal according to any one of claims 1 to 6 characterised in that it comprises 
third means for authenticating said second data processing means (30; 130) by said first data 
processing means (3; 29). 

8. A terminal according to claim 6 or claim 7 characterised in that it comprises a first 
communication channel (6) between said first data processing means (2; 3; 29) and said second 
data processing means (30; 130) and first means for securing said first communication channel. 

9. A terminal according to any one of claims 1 to 8 characterised in that it comprises 
fourth means for authentication of said terminal module (1; 101) by said user, independently of 
said personal security device (31; 131). 

10. A terminal according to claim 9 characterised in that said fourth authentication 
means comprise means for calculating by said first data processing means (2; 3; 29) and for 
presentating to said user via said second interface means (4) a password known to said user 
and calculated on the basis of a first secret parameter stored in said first data processing means 
(2; 3; 29). 


11. A terminal according to any one of claims 1 to 10 characterised in that it comprises 
fifth means for conjoint authentication of said terminal module (1; 101) and said personal security 
device (31; 131) by said user. 

12. A terminal according to claim 11 characterised in that said fifth authentication 
means comprise means for calculating by said device for executing said filter program (3; 29; 31 ; 
131) and for presentating to said user via said second interface means (4) a password known to 
said user and calculated on the basis of at least second and third secret parameters stored 
respectively in memory in said first data processing means (2; 3; 29) and in memory in said 
second data processing means (30; 130). 

13. A terminal according to any one of claims 1 to 12 characterised in that said 
terminal module (1) includes said programmable memory (3d) for loading and storing said filter 
program (F, 62). 

14. A terminal according to claim 13 characterised in that said filter program (F, 62) 
generates first commands for implementing said at least one sequence of exchanges of data 
between said terminal module (1) and said user and said first data processing means comprise a 
first microprocessor (2; 102) for controlling said interface means (4-9) programmed by virtue of 
said first software means (20/ 71) for controlling said interface means to execute said first 
commands generated by said filter program (F, 62), and a second secure microprocessor (3) of 
the integrated circuit card type disposed in said terminal module and including said 
programmable memory (3d), said second microprocessor (3) executing said filter program (F, 62) 
to control said at least one sequence of exchanges of data by means of said first commands 
sent to said first microprocessor (2) and for applying said at least one elementary command or 
sequence of elementary commands to said second data processing means. 

15. A terminal according to claim 14 characterised in that said first software means 
(20, 71) for controlling the interface means include at least a fourth secret parameter, said 
second microprocessor (3) being controlled by said filter program (F, 62) to authenticate said first 
software means (20, 71) for controlling the interface means on the basis of information sent by 
said first microprocessor (2) and combined at least with said fourth secret parameter. 

16. A terminal according to claim 15 characterised in that it comprises a second 
communication channel (12) between said first software means (20, 71) for controlling the 
interface means and said second microprocessor (3) and second means for securing said 
second communication channel. 

17. A terminal according to claim 16 characterised in that said second securing means 
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comprise means for encryption and decryption by said first software means (20, 71) and by said 
second microprocessor (3), of data sent on said second communication channel (12) on the 
basis of at least a fifth secret parameter stored in memory in said first and second data 
processing means. 

5 18. A terminal according to claim 16 or claim 17 characterised in that said second 

securing means comprise first physical means for protecting said second communication 
channel (12) against intrusion. 

19. A terminal according to any one of claims 15 to 18 characterised in that said first 
microprocessor (2) includes a temporary memory (2b) for storing said secret parameter and 

10 second means for physically protecting said temporary memory (2b) against intrusion. 

20. A terminal according to any one of claims 14 to 19 characterised in that said 
second microprocessor (2) is a microcontroller. 

21 . A terminal according to claim 13 characterised in that said filter program generates 
first commands for implementing said at least one sequence of data exchanges between said 

15 terminal module and said user and said first data processing means comprise said device for 
executing said filter program and consist in a secure microprocessor (29) adapted to: 

* execute said filter program (F, 62) for translating and converting said high-level 
requests into at least one sequence of data exchanges between the terminal module and the 
user and/or into at least one elementary command or a sequence of elementary commands that 

2 o can be executed by said second software means of said second data processing means (31), 

* control said interface means (4-9) using said first commands generated by said filter 
program to implement said at least one sequence of exchanges between said terminal module 
(1) and said user. 

22. A terminal according to claim 21 characterised in that said microprocessor (29) 

2 5 includes said programmable memory. 

23. A terminal according to claim 21 characterised in that said programmable memory 
is external to said microprocessor (29). 

24. A terminal according to claim 23 characterised in that said filter program (F, 62) is 
stored in encrypted form in said programmable memory and in that said microprocessor (29) 

3 o comprises means for reading, decrypting and executing said filter program. 

25. A terminal according to any one of claims 14 to 24 characterised in that said 
second data processing means of said personal security device (31) comprise a second data 
processing device (30) for secure execution of a filter program and a programmable memory 


(30a) for loading and storing said filter program (62), said first software means of said first data 
processing means being adapted to receive said commands for implementing said at least one 
sequence of exchange of data from either of said filter program executing devices (3; 29; 31) 
installed in said module and said personal security device, respectively. 

26. A terminal according to any one of claims 13 to 25 characterised in that: 

- said filter program (F, 62) comprises at least one secret parameter, 

- said second data processing means (30) comprise second means of conditional 
access control for authorising execution of said cryptographic computations in response to 
elementary commands generated by said filter program (F, 62) only if at least a second 
predefined condition depending on said secret parameter is satisfied. 

27. A terminal according to any one of claims 1 to 12 characterised in that said 
personal security device (131) includes said programmable memory (130a) for loading and 
storing said filter program (F, 62). 

28. A terminal according to claim 27 characterised in that said filter program (F, 62) 
generates first commands for implementing said at least one sequence of exchanges of data 
between said terminal module (1) and said user and said first data processing means comprise a 
first microprocessor (2; 102) for controlling said interface means (4-9), programmed by said first 
software means 
(20, 71), to execute said first commands generated by said filter program (F, 62), and said 
second data processing means comprise a secure second microprocessor (130) of the 
integrated circuit card type disposed in said personal security device (131) and including said 
programmable memory (130a), said second microprocessor (130) executing (i) said filter 
program (F, 62) for controlling said at least one sequence of exchanges of data by means of said 
first commands sent to said first microprocessor (2; 102), and (ii) said elementary commands. 

29. A terminal according to claim 6 and claim 28 characterised in that said first 
software means (20, 71) for controlling said interface means include at least one secret 
parameter and said second microprocessor (130) of said personal security device (131) is 
controlled by said filter software (62) to authenticate said first microprocessor (2) on the basis of 
information sent by said first microprocessor (2) and combined at least with said secret 
parameter. 

30. A terminal according to claim 28 or claim 29 characterised in that said second 
microprocessor (130) of said personal security device (131) is adapted to command the loading 
of said filter program (F, 62) into said programmable memory (130a) via said first interface 
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means (7-9) and said third interface means (6) with said personal security device (131). 

31. A terminal according to any one of claims 13 to 30 characterised in that said 
terminal module (1; 101) is an integrated circuit card reader and said personal security device is 
an integrated circuit card (31 ; 131). 
5 32. A terminal according to claim 13 characterised in that said terminal module (1) 

comprises a personal computer (102) and in that said reprogrammable memory is included in the 
hard disk (102b) of said computer. 

33. A terminal according to claim 32 and any one of claims 14 to 17 characterised in 
that said first microprocessor is the microprocessor (102c) of said personal computer (102), said 

1 o personal computer (1 02) being also interfaced to said secure microprocessor (3). 

34. A terminal according to claim 32 characterised in that said filter program (F) 
comprises a loading/decryption first module (Fed) and an encrypted second module (Fchi) for 
said translation of high-level requests, said first module (Fed) commanding the loading of said 
second module (Fchi) into RAM of said computer (102) and its decryption for execution of said 

1 5 filter program by said computer. 

35. A terminal according to claim 32 characterised in that said filter program (F) 
comprises at least one first module (F-PC) installed on said personal computer (102) and at least 
one second module (F-SE) installed on a security server (Ssec), said personal computer (102) 
and said security server (Ssec) being connected by a secure communication channel (CS) 

2 o enabling protected exchange of data between said modules. 

36. A terminal according to any one of claims 32 to 35 characterised in that said 
personal security device (31) is an integrated circuit card. 

37. A system for performing secure transactions characterised in that it comprises at 
least one terminal (1, 31; 101, 131) according to any one of claims 1 to 36 and at least one 

25 electronic unit (Sap; PC) including means for transmitting said high-level requests to said 
terminal(1,31; 101, 131). 

38. A system according to claim 37 characterised in that it comprises a plurality of 
terminals (1, 31; 101, 131), at least one server (S) constituting said electronic unit and means 
(CR) for sending digital data between said server (S) and said terminals. 


TITLE : Terminal and system for performing secure electronic transactions. 


ABSTRACT OF THE DISCLOSURE 

The terminal includes a terminal module (1) and a person security device (31). The 
terminal module (1) is adapted to receive requests from an application (Fap) installed on an 
electronic unit in the form of high-level requests independent of the module (1) and of said 
personal security device (31 ). 

The terminal module (1) and/or the personal security device (31) includes a 
reprogrammable memory for storing and means for executing a filter program (F) translating the 
high-level requests into at least one of either (i) at least one sequence of exchanges of data 
between the terminal module (1) and the user or (ii) at least one elementary command or a 
sequence of elementary commands that can be executed by the personal security device, 
together with means for protecting said filter program (F, 62) to prevent any modification of said 
program by an unauthorised person. The filter program comprises means for identifying and/or 
authenticating the source of requests sent by said application (Fap) installed in said unit. 
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